Re: [websec] WG Last Call on draft-ietf-websec-origin-02 until Aug-15

[Adam Barth <[e-mail]>]

On Sat, Aug 20, 2011 at 10:52 AM, Alexey Melnikov
<[e-mail]> wrote:
> Adam Barth wrote:
>
>> I've upload a new version of the draft, which incorporates all the
>> feedback I've received:
>>
>> http://www.ietf.org/id/draft-ietf-websec-origin-03.txt
>>
>> Please let me know if I've missed any feedback.
>>
> Hi Adam,
> Sorry, I forgot to send out my comments on -02:
>
> 3.2.1.  Examples
>
>  All of the following resources have the same origin:
>
>
>  http://example.com/
>  http://example.com:80/
>  http://example.com/path/file
>  http://example.com/
>
> The first and the last example are identical, was this intentional?

Nope.  Fixed.

> 4.  Origin of a URI
>
>  The origin of a URI is the value computed by the following algorithm:
>
>  1.  If the URI does not use a server-based naming authority, or if
>      the URI is not an absolute URI, then return a globally unique
>      identifier.
>
> [...]
>
>  6.  If there is no port component of the URI:
>
>      1.  Let uri-port be the default port for the protocol given by
>          uri-scheme.
>
>      Otherwise:
>
>      2.  Let uri-port be the port component of the URI.
>
> I know this is an obscure case, but what will this algorithm return for a
> mailto URI (assuming that it is supported)? I am not entirely clear that # 1
> applies here.

It's a globally unique identifier.  mailto doesn't use a server-based
naming authority.  For example, here's a nutty mailto URI:

mailto:[e-mail],[e-mail]

Although the common case of mailto URLs does contain the name of a
single server, the general case doesn't.  (Admitted, this probably
isn't as clearly defined as it could be.)

> 5.  Comparing Origins
>
>     NOTE: A URI is not necessarily same-origin with itself.  For
>     example, a data URI is not same-origin with itself because data
>
> An Informative reference for the "data" URI scheme is needed here.

Done.

>     URIs do not use a server-based naming authority and therefore have
>     globally unique identifiers as origins.
>
>
> 6.  Serializing Origins
>
>  This section defines how to serialize an origin to a unicode string
>  and to an ASCII string.
>
> Both Unicode and ASCII need references, I think they are normative.

Ok.  Are these the best references?

      <t>This section defines how to serialize an origin to a unicode <xref
      target="RFC5198" /> string and to an ASCII <xref target="RFC20" />
      string.</t>

Thanks,
Adam