On 2011-09-03 21:13, Adam Barth wrote:
On Fri, Sep 2, 2011 at 12:38 PM, Roy T. Fielding<fielding(_at_)gbiv(_dot_)com>
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?
<http://trac.tools.ietf.org/wg/httpbis/trac/browser/draft-ietf-httpbis/latest/p1-messaging.html>
But then, this is still work-in-progress.
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.
The best way to do it (as Roy agreed as well) is just to define the ABNF
for the field-value.
...
Best regards, Julian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf