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

From: Frank Ellermann <[email-masked]>
Date: Wed, 24 Aug 2011 19:37:08 +0200

Hi, a clear definition of "same origin" on standards track is a good thing.
Maybe some details could be improved:

1 - <OWS>, maybe I miss the point, but that is apparently the same as LWSP
    with an additional SHOULD to produce only a single SP.  If that is the
    case just saying LWSP would be clearer.  Caveat, the similar <OWS> in
    I-D.ietf-httpbis-p1-messaging-15 does not yet/more say that TAB is bad.
    If you insist on it please replace WSP by SP, and add HT to <obs-fold>.

2 - GUID, if this is supposed to be an UUID as described in RFC 4122 please
    say so.  Otherwise say *what* it is.  Reading section 4 I was sure that
    it talks about a "name-based UUID" (RFC 4122 section 4.3 for the URL
    namespace in appendix C of RFC 4122), a.k.a. UUID version 3 or 5.

    But later section 5 bullet 3 apparently expects UUID version 1 based
    on timestamps, and not some kind of "URI equality" as in version 3/5.

3 - i18n, the Unicode serialization is defined, but apparently not used.
    Is the draft actually designed for IRIs instead of URIs?  There is a
    "MUST support IDNA2003, if IDNA2008 is unsupported" in the i18n part:
    I don't get why if only URIs are affected.

    I think you want IRIs, and that's why you reference IDNA, please add
    a reference to RFC 3987 and use the correct term if that is the case.
    If you really only want URIs you could get rid of the unused Unicode
    serialization and the IDNA mustard.

4 - null
    For the Origin: HTTP header field the important serialization is in
    both cases ASCII, please swap sections 6.1 and 6.2, and limit the
    Unicode section to step 4.  Steps 1..3 and 5..6 are identical, and
    just saying "null" in the same style as "://" would be clearer than
    talking about U+006E, U+0075, U+006C, U+006C in the ASCII section.

    If what you really want is a case-sensitive lower-case string "null"
    the ABNF notation for both serializations should be %x6E.75.6C.6C or
    similar.

5 - www, obviously you decided that there will be no exception for www.
    Maybe note why in the FAQ (section 3.2).  I can't say that I like
    the concept "different port or different scheme is never the same
    origin", but at least it is clear, and automatically covers https:.

-Frank

---

From: Julian Reschke <[email-masked]>
Date: Thu, 25 Aug 2011 18:32:24 +0200

Below a few late comments..

6. Serializing Origins

- It really really seems that the two algorithms need to be swapped (the 
first one converts to ASCII, but the second does not).

- Also, I'd prefer a declarative definition.

7. The HTTP Origin header

- header *field*

- the syntax doesn't allow multiple header fields, and the prose says 
clients MUST NOT generate them; what is the recipient supposed to do 
when it get's multiple instances anyway? Is the default approach 
(ignoring them all) good enough? Do we need to warn recipients so that 
they check?

11. References

- the WEBSOCKETS reference should be updated (if a new draft is produced)

Best regards, Julian