- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 9 Jul 2009 11:39:06 +1000
- To: Adam Barth <w3c@adambarth.com>, Ian Hickson <ian@hixie.ch>, collinj@cs.stanford.edu
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
A few notes, mostly editorial. * It would be helpful to give more information about the use case and applicability of this header in the Introduction. * Likewise, it would be very helpful if it was positioned in relation to Referer and Origin, perhaps in an Appendix. * Section 2 talks about applying the IDNA ToASCII algorithm to parts of a URI. This doesn't make sense; perhaps you mean IRI? * The /variable/ syntax is distracting. * Specifying RFC2119 requirements as "Implementations MUST use the following algorithm..." isn't good practice, as discussed previously. E.g., section 2 would be better specified as: ---8<--- 2. Origin The origin is used to [whatever function this component has; it isn't yet explained]. Usually, an origin is a tuple of (scheme, host, port). However, implementations MAY define other types of origins; for example, user agents could have a concept of a globally unique origin, or a certificate-based origin. However, computation and use of such origins are outside the scope of this specification. An origin is computed for a given URI [RFC3986]. [ or is this really an IRI? see above ] If the URI cannot be parsed, does not contain an authority component (see RFC3986 Section 3.2), or is a relative reference ([RFC3986] Section 4.2) the origin MUST NOT be computed. If the URI's scheme is not supported by the implementation, the origin MUST NOT be computed. If the scheme is 'file', then an implementation MAY refuse to compute an origin as well [ this needs to change to reflect the purpose of this clause ]. When computing an origin, the host MUST be converted to lowercase. If there is no port in the URI, it MUST be considered to be the default port for the scheme. --->8--- * Just FYI, IDNA is currently being revised; see <http://tools.ietf.org/wg/idnabis/ >. * There's a lot instances of 'implementation-defined value' in prose, but no context of what these are, how they might be used, etc. * Section 5 places requirements on User Agents. I'm assuming you mean UAs that conform to *this* specification; if so, it would be good to spell this out (either here or in a conformance criteria section). * The header field-value is defined as containing LWS characters. There isn't a reference for that rule, and FYI that form is being deprecated by HTTPbis; it would probably be better to say one or more whitespace characters. Another option would be to make it a comma- separated list, to pull it in line with the definitions of other HTTP headers. -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 9 July 2009 01:39:50 UTC