This is the set of open issues encountered in the Mandatory spec (submitted as Internet Draft, March 23, 1998). They should all be closed out in the recent August 7 draft.
| No | Name | Status | Short Description | Proposed Resolution | Raised by |
| 1 | END_TO_END | Closed | The notion that end-to-end doesn't necessarily mean user-agent to origin server has caused a lot of discussion | Consensus that the current working in Mandatory is correct. A solution to the discussion was proposed to a) take out the current wording in Mandatory and leave it "as defined in HTTP" and b) do one of the following in order of preference: 1) Make a plea to the HTTP group that the notion of end-to-end is clarified in HTTP/1.1 spec as currently stated in Mandatory 2) Make a note in the (now yet written) extension guide lines discussing the floating notion of end-to-end. HTTP/1.1 section 13.5.2. has been clarified so that we can expect it to be discussed there. | hardie |
| 2 | EXPECT | Closed | Problem: Expect can't be enforced. Semantically close to C-Opt: A hop-by-hop header field with an optional extension. Difference: Expect is request-only, C-Opt is request/response. | Deprecate Expect in favor of C-Opt and take it to the HTTP WG | leach |
| 3 | DECL_PARAMETERS | Closed | Should we support both header fields and parameters. Henrik thinks so, Yaron don't. Comments needed | All unknown extension parameters are for the mandatory extension mechanism itself and *not* for the extension. | goland |
| 4 | 510_INFO | Closed | "The server SHOULD send back all the information necessary for the client to issue an extended request." Either delete this SHOULD or specify the information sending mechanism. | holtman | |
| 5 | EXTENSION_LIFETIME | Closed | What is a reasonable lifetime? | Make it clear that extensions can be used independently of whether the extension is "resolvable" or not. | kristol |
| 6 | IANA_ROOT | Closed | In 3.0 the relative URIs relating to IANA don't seem to match real IANA URIs (RFCs have .txt appended, for example) and IANA runs several registries, so it is not clear which one a specific relative URI would relate to. | Given that the DRUMS header registry won't be along soon, we're going with RFC-declared headers as the allowable tokens; everything else must be a full URI | hardie |
| 7 | REPEATED_EXTENSIONS | Closed | MUST or SHOULD applications NOT reuse existing prefixes? | The idea is to support "repeated" hop-by-hop extensions like for example a hit-count like mechanism. | fielding |
| 8 | MANDATORY_RESPONSE | Closed | Is it allowed for a server to add unsolicited Mandatory header fields in responses and what does it mean? | The current proposed resolution for MANDATORY_RESPONSE is that servers never be allowed to add unsolicited Mandatory headers, but they could add Optional headers | goland |
| 9 | EXT_DECL_BNF_BUG | Editorial/Closed | There is an extra ";" in the definition in section 3 | Typo - Just remove it | goland |
| 10 | CHANGE_NAME | Editorial/Closed | "Mandatory" is a bad name | Use "Mandatory and Optional Extension Framework for HTTP" | Discussed at the LA IETF BOF |
| 11 | DYNAMIC_NS | Editorial/Closed | It must be made clear that ns values are dynamically generated | goland | |
| 12 | LAYERING_NOTE | Editorial/Closed | Confusion about note on parameters and layers | Just remove it - it doesn't serve any purpose | kristol |
| 13 | CLARIFY_510 | Editorial/Closed | The second and third paragraphs in section 7 really confuse me. Could you please clarify? | goland | |
| 14 | URI_REFS | Editorial/Closed | Need references to CIDs and UUIDs | UUID is an ID, CID is in RFC 2111 | kristol |
| 15 | EXT_PROCESSING | Editorial/Closed | The layered approach in 5.0 implies that the last step is to apply the semantics of the method without "M-". The language needs to be tightened to indicate that the semantics may be derived from the base method, but they should not be assumed. | hardie | |
| 16 | REUSE_HEADER_PREFIX | Closed | In 3.1, the parenthetical remark is a bit strange (why is that discussion relevant to that rule?), but the rule itself is clear. | Subsumed by REPEATED_EXTENSIONS | holtman |
| 17 | UNCONDITIONAL_COMPLIANCE | Closed | Does the indication of an extension mean unconditionally compliant? | Proposed wording and discussion. Leave it as is | mogul |
| 18 | NO_AGENT | Closed | Section 3.1 "Header Field Prefixes" uses the term "agent", which is new in the HTTP context. I presume it to mean "a thing that generates headers", and that it is explicitly not the same as a "server", although I can't figure out why. | Proposed wording | patterson |
| 19 | END_TO_END | Closed | Section 4.1 "End-to-End Extensions" states that "Proxies MAT act as both the initiator and the ultimate recipient of end-to-end extension declarations." This is another carryover from the PEP draft, but violates the normal IETF usage of "end-to-end". | Proposed wording | patterson |
| 20 | MAN_RESPONSE | Closed | My point was that the draft makes a big deal out of the "mandatoryness" of Man and C-Man headers, and rightfully so. "mandatory" starts to look like "mandatory to compliant readers and optional to others", which just doesn't sound right. | Proposed wording | patterson |
| 21 | HTTP10_PROXY | Closed | Problem with HTTP/1.0 proxy that forwards the M-method and does not strip the Connection header field. I assume the solution to this is to D8ignore/error any mandatory extension received with HTTP/1.0 as the request HTTP-version | Proposed wording | fielding |
| 22 | AVOID_NS | Closed | Is there a way to say that an application doesn't accept name spaces? | Leave it as is | lawrence |
| 23 | BAD_EXAMPLES | Closed | The example in section 13.2 "Server Uses ZipFlate Compression Extension" is another simplified carry-over from the PEP draft, but calls out some very interesting issues that don't arise earlier in the document, at least not obviously: | Leave as it. As a result of the fixed wording in MAN_RESPONSE, they make more sense now. | patterson |