W3C home > Mailing lists > Public > uri@w3.org > September 2009

Re: [hybi] ws: and wss: schemes

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 04 Sep 2009 22:05:36 +0200
Message-ID: <4AA17310.1090108@gmx.de>
To: Ian Hickson <ian@hixie.ch>
CC: URI <uri@w3.org>, "hybi@ietf.org" <hybi@ietf.org>, "uri-review@ietf.org" <uri-review@ietf.org>, "public-i18n-core@w3.org" <public-i18n-core@w3.org>
Ian Hickson wrote:
> ...
>> 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.
> ...

But that's not who registering an URI scheme works. Check the relevant 
RFCs. Essentially you register the *URI* scheme, and get IRIs based on 
the mapping rules defined in RFC 3987.

>>>> 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?

I haven't checked yet.

It would be helpful if you didn't abuse the IETF ID submission system as 
local storage, and only submitted new drafts when you want community 
review. Is now a good moment to read it?

> ...
>> 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.
> ...

The RFC reference is immutable. Just paste the content in your source 
file, and change the anchor attribute value.

>>> 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.
> ...

You can't register an IRI scheme. (Unless I missed something).

 > ...
>> 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?

Nope. (See above)

 > ...
>>>> 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?

You need to state how you want to encode non-ASCII characters. "See 
RFC3987" goes into the right direction but really isn't sufficient. 
Please see RFC 4395, Section 2.6:

"2.6. Internationalization and Character Encoding

    When describing URI schemes in which (some of) the elements of the
    URI are actually representations of human-readable text, care should
    be taken not to introduce unnecessary variety in the ways in which
    characters are encoded into octets and then into URI characters; see
    RFC 3987 [6] and Section 2.5 of RFC 3986 [5] for guidelines.  If URIs
    of a scheme contain any text fields, the scheme definition MUST
    describe the ways in which characters are encoded, and any
    compatibility issues with IRIs of the scheme."

BR, Julian
Received on Friday, 4 September 2009 20:06:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:42 GMT