Re: [websec] Last Call: <draft-ietf-websec-origin-04.txt> (The Web Origin Concept) to Proposed Standard

[Adam Barth <[e-mail]>]

On Fri, Sep 2, 2011 at 12:38 PM, Roy T. Fielding <[e-mail]> wrote:
> On Aug 23, 2011, at 2:19 PM, The IESG wrote:
>> The IESG has received a request from the Web Security WG (websec) to
>> consider the following document:
>> - 'The Web Origin Concept'
>>  <draft-ietf-websec-origin-04.txt> as a Proposed Standard
>
> Sec 2.2: the definition of OWS includes a mistake that I just fixed in httpbis.
>
>   OWS            = *( [ obs-fold ] WSP )
>                    ; "optional" whitespace
>   obs-fold       = CRLF
>
> should be
>
>   OWS            = *( HTAB / SP / obs-fold )
>                    ; "optional" whitespace
>   obs-fold       = CRLF ( HTAB / SP )
>                    ; obsolete line folding
>
> The problem isn't in OWS itself -- the above are equivalent.
> It is the definition of obs-fold that is wrong because it stands
> for the obsolete line folding allowed by RFC2616 (RFC822, etc.).
> A CRLF alone is not an obs-fold, so optimizing the ABNF in that
> way was wrong in httpbis.  Likewise, I recommend replacing WSP with
> its equivalent ( HTAB / SP ) because the name is misleading and
> is only used in this one section.

This text is intended to match the text from HTTPbis.  The most
recently published HTTPbis documents still contain the old
construction:

http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-16#section-1.2.2

Is there some way to see the as-yet-unpublished version with the
updated text so I can make sure to get it exactly right?

> OTOH, perhaps a simpler change is in order.  The above definitions
> are only used once in the document (Section 7.1).  Furthermore,
> since we are defining a new header field (and not all header fields),
> we can be more proscriptive in 7.1 and remove the section above.
>
> In 7.1, instead of
>
>   origin              = "Origin:" OWS origin-list-or-null OWS
>
> define it as
>
>   origin              = "Origin:" [ SP ] origin-list-or-null
>
> and then most of 2.2 can be removed.

Is there some advantage in doing that?  It seems better to define this
header in the same way we define all the other headers.  If we do
something different here, we run the risk of confusing folks into
thinking that it requires some sort of different generation or parsing
than everything else.

> Sec 8: typo:  s/those model /those models /

Fixed.

> Otherwise, the spec looks good.

Thanks!

Adam