W3C Architecture Domain HTTP

IETF Mandatory Spec Issues List

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


Henrik Frystyk Nielsen.
@(#) $Id: Overview.html,v 1.4 2014/02/24 23:09:32 sysbot Exp $