Re: [hybi] ws: and wss: schemes

Julian Reschke <julian.reschke@gmx.de> Fri, 04 September 2009 20:05 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674DA3A6833 for <hybi@core3.amsl.com>; Fri, 4 Sep 2009 13:05:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.955
X-Spam-Level:
X-Spam-Status: No, score=-4.955 tagged_above=-999 required=5 tests=[AWL=-2.356, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUlg67f3u-FE for <hybi@core3.amsl.com>; Fri, 4 Sep 2009 13:05:26 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 03E633A67DA for <hybi@ietf.org>; Fri, 4 Sep 2009 13:05:25 -0700 (PDT)
Received: (qmail invoked by alias); 04 Sep 2009 20:05:45 -0000
Received: from p508FCDE6.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.205.230] by mail.gmx.net (mp066) with SMTP; 04 Sep 2009 22:05:45 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/ljlxijOTlriSnNDLlMnq8oOx2zUDIniLKTNo5xy /bqS8UoBzkzLuB
Message-ID: <4AA17310.1090108@gmx.de>
Date: Fri, 04 Sep 2009 22:05:36 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
MIME-Version: 1.0
To: Ian Hickson <ian@hixie.ch>
References: <OF22CD1320.96C55266-ON85257610.004AB599-85257610.004BC9CA@lotus.com> <C9931C12-E123-437D-8E7D-F8C680C62397@mnot.net> <4A8CAA72.3000209@berkeley.edu> <Pine.LNX.4.62.0909040147300.6775@hixie.dreamhostps.com> <4AA14792.4020009@gmx.de> <4D25F22093241741BC1D0EEBC2DBB1DA01AD6282C2@EX-SEA5-D.ant.amazon.com> <Pine.LNX.4.62.0909041947250.26930@hixie.dreamhostps.com>
In-Reply-To: <Pine.LNX.4.62.0909041947250.26930@hixie.dreamhostps.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.51
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>
Subject: Re: [hybi] ws: and wss: schemes
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2009 20:05:27 -0000

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