Subject: Re: The HTTP Sec-From Header (draft-abarth-origin)

From: =JeffH <[email-masked]>
Date: Tue, 27 Oct 2009 16:15:15 -0700

draft-abarth-origin-05  features this ABNF..

      origin            = "origin" ":" OWS [ "null" / origin-list ] OWS
      origin-list       = serialized-origin *( 1*SP serialized-origin )
      serialized-origin = scheme "://" host [ ":" port ]
       ; <scheme>, <host>, <port> productions from RFC3986

..with provisio that it is "...ABNF [RFC5234] grammar..."

However, I cannot find the production for <OWS> in either 
draft-abarth-origin-05 or  [RFC5234].

Also, why is serialized-origin delimited explicitly by spaces ( 1*SP ) and not 
simply whitespace e.g. 1*WSP ?  where <WSP> is from [RFC5234]..

          WSP            =  SP / HTAB
                                 ; white space

?

=JeffH

---

From: Adam Barth <[email-masked]>
Date: Tue, 27 Oct 2009 20:19:33 -0700

> draft-abarth-origin-05 or  [RFC5234].

I have no idea what it means.  That's what Julian Reschke told me to
put there.  We're not trying to be innovative.  We're just trying to
spec a normal HTTP header.  It's kind of annoying that it's this
tricky

> Also, why is serialized-origin delimited explicitly by spaces ( 1*SP ) and
> not simply whitespace e.g. 1*WSP ?  where <WSP> is from [RFC5234]..
>
>         WSP            =  SP / HTAB
>                                ; white space
>
> ?

The latest version (which I might not have uploaded yet) actually just
specs SP.  That's what Anne wanted.  We're going to talk about this
issue at TPAC and figure out what delimiter we want to use here.  The
other option Anne is considering is a comma, as requested by mnot.  My
understanding is there are some subtleties in CORS at play.

Adam

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 Oct 2009 08:09:25 +0100

Adam Barth wrote:
> ...

OWS is defined in HTTPbis, so you would need to reference 
<http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-08#section-1.2.2>, 
or copy the related ABNF rules (with the risk of future changes in HTTPbis).

BR, Julian