Re: [hybi] ws: and wss: schemes

Julian Reschke <julian.reschke@gmx.de> Thu, 17 September 2009 11:38 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 B37A93A69B6 for <hybi@core3.amsl.com>; Thu, 17 Sep 2009 04:38:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.619
X-Spam-Level:
X-Spam-Status: No, score=-4.619 tagged_above=-999 required=5 tests=[AWL=-2.020, 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 mkqf52oYBGSe for <hybi@core3.amsl.com>; Thu, 17 Sep 2009 04:38:34 -0700 (PDT)
Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 756AD3A685C for <hybi@ietf.org>; Thu, 17 Sep 2009 04:38:34 -0700 (PDT)
Received: (qmail invoked by alias); 17 Sep 2009 11:39:25 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.117]) [217.91.35.233] by mail.gmx.net (mp026) with SMTP; 17 Sep 2009 13:39:25 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18fZfAdcMYfXa+dnhYdwBTioeTKcS2mR5tHqFDZe3 FkDuvuPi9Lpncx
Message-ID: <4AB21FD6.3070008@gmx.de>
Date: Thu, 17 Sep 2009 13:39:02 +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: <Pine.LNX.4.62.0908070531430.28566@hixie.dreamhostps.com> <1249651007.25446.8934.camel@dbooth-laptop> <0B450D619CC0486E8BD51C31FBA214AD@POCZTOWIEC> <20090812021926.GC19298@shareable.org> <AB9A0CF094F04D39BC7DC5DEAFF7FC1C@POCZTOWIEC> <4AA8A2CE.3000801@it.aoyama.ac.jp> <34660A8503164BE88641374ADF2BF1A3@POCZTOWIEC> <20090910124618.GB32178@shareable.org> <11DFA16908CB4B7D8AF0F45975DE425A@POCZTOWIEC> <20090910224151.GA17387@shareable.org> <Pine.LNX.4.62.0909170834040.14605@hixie.dreamhostps.com>
In-Reply-To: <Pine.LNX.4.62.0909170834040.14605@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.57
Cc: URI <uri@w3.org>, hybi@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: Thu, 17 Sep 2009 11:38:35 -0000

Ian Hickson wrote:
> ...
>> Then the encoding considerations should be something like:
>>
>>   Because many characters are not permitted with this syntax, the
>>   "heir-part" and "query" elements may contain characters from the
>>   Unicode Character Set [UCS] as suggested by URI [RFC3986] using the
>>   reg-name and percent-encoding translations of IRI to URI
>>   mapping [RFC3937]. Translation is performed by first encoding those
>>   Unicode characters as octets to the UTF-8 character
>>   encoding [RFC3629]. Replace the reg-name part of the heir-part by
>>   the part converted using the ToASCII operation specified in section
>>   4.1 of [RFC3490] on each dot-separated label, and by using U+002E
>>   (FULL STOP) as a label separator, with the flag UseSTD3ASCIIRules
>>   set to TRUE, and with the flag AllowUnassigned set to TRUE. Then
>>   only those octets that do not correspond to characters in the
>>   unreserved set should be percent-encoded.
>>
>>   By using UTF-8 encoding, there are no known compatibility issues
>>   with mapping Internationlized Resource Identifiers to websocket
>>   URIs according to [RFC3987].
> 
> I've used the above as a guide for what to put in the spec. I didn't use 
> it literally because it seemed to misuse RFC2119 terminology, and it 
> wasn't clear to me where the descriptive ended and the normative started. 
> I hope the text now in the spec makes sense. Let me know if it needs more 
> work.
> ...

It now says:

>    Encoding considerations.
>       Characters in the host component that are excluded by the syntax
>       defined above must be converted from Unicode to ASCII by applying
>       the IDNA ToASCII algorithm to the Unicode host name, with both the
>       AllowUnassigned and UseSTD3ASCIIRules flags set, and using the
>       result of this algorithm as the host in the URI.
> 
>       Characters in other components that are excluded by the syntax
>       defined above must be converted from Unicode to ASCII by first
>       encoding the characters as UTF-8 and then replacing the
>       corresponding bytes using their percent-encoded form as defined in
>       the URI and IRI specification.  [RFC3986] [RFC3987]

I think that's good, except that the mention of IRI in the last sentence 
seems to be superfluous. RFC3986 already defines everything that is 
needed here. Or is there something specific from the IRI spec you think 
is relevant? (In which case it should state that more clearly).

BR, Julian