Subject: [apps-discuss] Comments on draft-ietf-websec-origin-00.txt

From: Bill McQuillan <[email-masked]>
Date: Thu, 30 Dec 2010 22:53:11 -0800

My comments on draft-ietf-websec-origin-00.

2.2.  Syntax Notation

The use of <obs-fold> allows for header fields containing lines 
with nothing but spaces and tabs. Does http handle this?

--------------------

4.  Comparing Origins

Although Section 3 discusses an "implementation-defined value" 
and '"sandbox" bits', the comparison algorithm does not mention 
how these are to be handled.

--------------------

5.  Serializing Origins

The "implementation-defined value" and '"sandbox" bits' are not 
discussed in the serialization algorithm.

-----

In step 5 of each algorithm the port is omitted if it is not
"different than the default port". This could be problem since it 
requires three different algorithms to agree on that default.

  1 - At the point where the resource is fetched from the 
      "origin" and the default port MUST be known if the
      correct connection is to be made.
      
  2 - At the serialization point.
  
  3 - At the server receiving the "Origin:" header field.

Instead I recommend that the actual port always be included in 
the serialization to avoid ambiguity. After all it's mainly for 
machine consumption.

--------------------

6.  The HTTP Origin header
6.2.  Semantics

It is not clear what the meaning of multiple origins is. Should 
the client issuing a request include all of the origins that it 
knows about? This might make it more likely that the server 
receiving the request would find an origin it "likes". Or it 
might make it more likely that the server would find an 
objectionable origin. What "meaning" is the client trying to 
communicate to the server?

-----

6.3.  User Agent Requirements

The rule about "two consecutive serialized-origin productions" 
not being identical implies that there is some semantics in the 
ordering of the serialized origins in an Origin header field. 

Also the mention of the way that the "ascii-serialization of the 
origin of previous-uri" is appended to the previous request 
Origin header field implies an ordering.

Does ordering have any semantics in the Origin header field?

-- 
Bill McQuillan <[email-masked]>

---

From: Barry Leiba <[email-masked]>
Date: Fri, 31 Dec 2010 08:42:57 -0500

> My comments on draft-ietf-websec-origin-00.

You should post these, along with any other comments you have on the
websec work, to the websec WG mailing list, <[email-masked]>.

Barry