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

Thank you for your comments.

On Wed, Jul 8, 2009 at 6:39 PM, Mark Nottingham<mnot@mnot.net> wrote:
> * It would be helpful to give more information about the use case and
> applicability of this header in the Introduction.

Will do.

> * Likewise, it would be very helpful if it was positioned in relation to
> Referer and Origin, perhaps in an Appendix.

Will do.

> * Section 2 talks about applying the IDNA ToASCII algorithm to parts of a
> URI. This doesn't make sense; perhaps you mean IRI?

I'm a bit unclear on the difference between URIs and IRIs.  Is there
are  a good reference you could point me to?

> * The /variable/ syntax is distracting.

Is there a standard way of distinguishing variables from
non-variables?  In non-ASCII specs, I've seen italics used for this
purpose.

> * 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:

The preference for one or the other seems to vary by community.  The
algorithmic parts of the spec originated from HTML 5, which is largely
written in that style.  I can change to the declarative style if Ian
doesn't think that will cause a problem for HTML 5.

> * Just FYI, IDNA is currently being revised; see
> <http://tools.ietf.org/wg/idnabis/>.

I also have little understanding of IDNA.

> * There's a lot instances of 'implementation-defined value' in prose, but no
> context of what these are, how they might be used, etc.

Maybe some examples would clarify the situation?  Ian has asked me to
specify what these actually are, which is another alternative.

> * 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).

Will do.

> * 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.

My understanding is that using a comma-separated list would change the
semantics because of header coalescing.  Saying "whitespace" seems
less precise than LWS.  Is whitespace defined precisely somewhere in
HTTPbis that I can reference?

Adam

Received on Thursday, 9 July 2009 05:59:28 UTC