Comments on the HTTP Sec-From Header (draft-abarth-origin)

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