Re: [hybi] ws: and wss: schemes

On Fri, 4 Sep 2009, Julian Reschke wrote:
> Ian Hickson wrote:
> > On Fri, 14 Aug 2009, Julian Reschke wrote:
> > > [...] it now says:
> > > 
> > > >    URI scheme syntax.
> > > >       In ABNF terms using the terminals from the IRI specifications:
> > > >       [RFC5238] [RFC3987]
> > > > 
> > > >            "ws" ":" ihier-part [ "?" iquery ]
> > > That is even worse than before, because it now uses productions from the
> > > IRI spec defining *URI* syntax.
> > 
> > ws: and wss: URLs are i18n-aware; why would we want to limit them to ASCII?
> 
> Because that's how URI and thus URLs are defined.

The ws: and wss: URLs are IRIs; why would we limit them to URIs? I'm not 
especially interested in ASCII-only URIs at this point. These URLs are 
only ever going to be used in contexts that accept full IRIs.


> > > Furthermore, it still doesn't answer what the semantics of these 
> > > parts are. What do "ihier-part" and "iquery" represent in a ws URI?
> > 
> > This is defined by the RFC 3987, no? Surely we wouldn't want IRI 
> > components to have different meanings in different schemes?
> 
> If you can point to a section in RFC 3987 which defines more than the 
> syntax, and can state that that also applies to "ws", then, great...

Isn't what the Web Socket protocol spec now says suitable?


> > On Fri, 14 Aug 2009, Julian Reschke wrote:
> > > Ian Hickson wrote:
> > > > > I assume you are using ABNF syntax (RFC5234) and terminology from the
> > > > > URI
> > > > > spec, but you really need to state that.
> > > > Thanks, fixed.
> > > > 
> > > > (I tried referencing STD68 instead of RFC5234, as we do in HTML5, but
> > > > apparently there's no index of STD references for xml2rfc?)
> > > Just day "STD68" instead of "RFC5234" in the reference/@anchor element.
> > 
> > I have no <reference> elements, I'm using the <?rfc include=""?> feature and
> > reference.RFC.xxxx.xml files. I couldn't find STD reference files.
> 
> Don't use the include feature then.

The reference feature allows me to automatically generate the references, 
which is of more benefit to me than referencing STD numbers instead of 
RFC numbers.


> > I've deferred to RFC3987 to sidestep this issue.
> 
> A URI is not a IRI.
> 
> You can refer to the mapping, but that really needs a few more words 
> than "See RFC3987.".

I don't care about the URI part, only the IRI part.


On Fri, 4 Sep 2009, Phillips, Addison wrote:
> 
> I agree with Julian. If you are defining a URI syntax, you can't use IRI 
> to do so.

I've no intention of defining a URI, only an IRI.


> Section 2.5 of URI, however, does allow what you mean here, when it 
> says:
> 
>    When a new URI scheme defines a component that represents textual
>    data consisting of characters from the Universal Character Set [UCS],
>    the data should first be encoded as octets according to the UTF-8
>    character encoding [STD63]; then only those octets that do not
>    correspond to characters in the unreserved set should be percent-
>    encoded.  For example, the character A would be represented as "A",
>    the character LATIN CAPITAL LETTER A WITH GRAVE would be represented
>    as "%C3%80", and the character KATAKANA LETTER A would be represented
>    as "%E3%82%A2".
> 
> If 'ws:' were defined as an IRI scheme, you could then use RFC 3987 to 
> define its mapping to a URI. This is what is done in specs like XLink 
> 1.1. Defining 'ws:' as an IRI scheme would not necessarily be a bad 
> thing

Ok... Let's do that then. I couldn't find any documentation on how to do 
that. I've just changed the words "URI" to "IRI" in the registration. Is 
that what needs to happen?


> I've found that confusion tends to surround when an IRI is 
> happily being an IRI and when it needs to be mapped down to a URI.

I'm still confused as to why we still have URIs at all. They're such an 
anachronism.


> > > I've deferred to RFC3987 to sidestep this issue.
> > 
> > A URI is not a IRI.
> > 
> > You can refer to the mapping, but that really needs a few more words 
> > than "See RFC3987.".
> 
> It may not need many more words, but certainly a few more words.

Could you elaborate? Which words should I add?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 4 September 2009 19:52:07 UTC