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

Thanks for your comments Mark.  I've updated the draft, but I have not
yet addressed all of your comments.  I tried to handle the technical
comments in this round.  I'll hand the presentational comments in the
next round.  Detailed response below.

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.
>
> * Likewise, it would be very helpful if it was positioned in relation to
> Referer and Origin, perhaps in an Appendix.

I've pushed these comments to the next version.

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

I will address these comments when I have some time to study all the
various URL/URI/IRI/DanCURL possibilities.

> * The /variable/ syntax is distracting.

There were some good alternatives suggested later in the thread.  I'll
probably move to hyphenated variable names in the next draft.

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

I've pushed deciding whether to present the requirements as algorithms
or declaratively to the next draft.

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

It's difficult to write down a correct spec here because these vary
from implementation to implementation.

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

Oops.  Missed this one.  I'll get it next time.

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

Done.  I didn't quote the origin values as you suggest in a later
message because I don't believe it's possible to have a comma or a
space in an origin serialization.

Adam

Received on Friday, 31 July 2009 19:44:30 UTC