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

[Adam Barth <[e-mail]>]

On Mon, Aug 22, 2011 at 1:50 AM, Alexey Melnikov
<[e-mail]> wrote:
> Hi Adam,
>
> Adam Barth wrote:
>
>> 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.
>>
> Exactly my point. At first I thought that you meant URI scheme which allows
> for the <authority> component, but it seems like you are trying to define a
> wider category.

I've reworked this phrase to more directly reference Section 3.2 of
RFC3986 (and I added an explicit reference).

>>> 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>
>>
>
> Something like:
>
>  [Unicode52]  The Unicode Consortium.  The Unicode Standard, Version
>               5.2.0, defined by: "The Unicode Standard, Version
>               5.2.0", (Mountain View, CA: The Unicode Consortium,
>               2009. ISBN 978-1-936213-00-9).
>
> for Unicode. Probably worth pointing to Unicode 6.0 though.
>
> I think RFC 20 is Ok.
>
>               <http://www.unicode.org/versions/Unicode5.2.0/>.

Done.

Adam