On Mon, Aug 22, 2011 at 1:50 AM, Alexey Melnikov <[email protected]> wrote: > Hi Adam, > > Adam Barth wrote: > >> On Sat, Aug 20, 2011 at 10:52 AM, Alexey Melnikov >> <[email protected]> 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:[email protected],[email protected] >> >> 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 _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
