- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 14 Jun 2012 20:54:28 +1000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 14/06/2012, at 5:29 PM, Julian Reschke wrote: > On 2012-06-14 05:23, Mark Nottingham wrote: >> >> On 13/06/2012, at 8:55 PM, Julian Reschke wrote: >>>>> >>>>> Cache directives are identified by a token, to be compared case- >>>>> insensitively, and have an optional argument, that can use both token >>>>> and quoted-string syntax. For the directives defined below that >>>>> define arguments, recipients ought to accept both forms, even if one >>>>> is documented to be preferred. For any other directive, recipients >>>>> MUST accept both forms. >>>> >>>> You've managed to qualify it for those defined below, but not for "any other directive." >>> >>> Indeed... How about: >>> >>> Cache directives are identified by a token, to be compared case- >>> insensitively, and have an optional argument, that can use both token >>> and quoted-string syntax. For the directives defined below that >>> define arguments, recipients ought to accept both forms, even if one >>> is documented to be preferred. For any directive not defined by this >>> specification, recipients MUST accept both forms. >>> >>> ? (<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/307/307.4.diff>) >> >> Still managing to avoid it. The last sentence needs to say something like: >> >> """ >> For any other directive that accepts an argument, recipients MUST accept both forms. >> """ > > I believe that all new directives should not only be parseable with a generic parser, but also that senders can *rely* on them being parsed that way; see James' explanation. And that's fine; I'm just wondering why we're encouraging this with a MUST, where we haven't done so anywhere else, AFAICT. >>> It means that you add new special cases to something that is already unnecessarily complex. Why would you want to do that? >> >> What special cases? >> >> For example, if I define a new directive that takes an URL as its argument, I might decide to say that it should ONLY use the quoted form, because I know that people will mess it up if they use token. How does that make things more complex? Your generic parser works the same. > > It's a special case in libraries that *construct* the header field. To conform to the SHOULD requirement, they'd have to understand the new directive. OK. >> Likewise for auth schemes: <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p7-auth.html#considerations.for.new.authentication.schemes> > > That is incorrect. We've had these requirements all the time based on the ABNF. Yes, but we haven't surfaced them as conformance requirements for auth schemes like we are here. Why is this different? >> We don't place any conformance requirements on media type parameters either: <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#media.types>; we only note that they can be transmitted in either form. Why not use similar language here? > > It says: > >> The type/subtype MAY be followed by parameters in the form of attribute/value pairs. >> >> parameter = attribute "=" value >> attribute = token >> value = word >> >> The type, subtype, and parameter attribute names are case-insensitive. Parameter values might or might not be case-sensitive, depending on the semantics of the parameter name. The presence or absence of a parameter might be significant to the processing of a media-type, depending on its definition within the media type registry. >> >> A parameter value that matches the token production can be transmitted as either a token or within a quoted-string. The quoted and unquoted values are equivalent. > > So I don't see any language here that would allow a parameter to restrict the serialization within the header field. I think what I'm most concerned about here is that (in all of these cases, not just CC directives), we're requiring people to read between the lines. If we want to assure interoperability, we need to spell it out, e.g.,: """ Receivers of Cache-Control directives ought to be able to parse all three forms of directive (without a value, with a token value, and with a quoted-string value) for all directives. """ And, separately in the cache control extensions section: """ New cache control extension directives are encouraged to: - Define whether or not they allow or require a parameter - If they do accept a parameter, allow it to occur in either token or quoted-string form (restricting to one form requires sending libraries to special-case the directive) - If they do accept a parameter, define how a directive without one should be interpreted - If they do not accept a parameter, define how a parameter with one should be interpreted - If they do accept a parameter, define how multiple occurrences should be handled """ -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 14 June 2012 10:54:57 UTC