Re: [hybi] ws: and wss: schemes

Ian Hickson <ian@hixie.ch> Fri, 04 September 2009 19:52 UTC

Return-Path: <ian@hixie.ch>
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 4680028C11A; Fri, 4 Sep 2009 12:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.549
X-Spam-Level:
X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, GB_I_LETTER=-2]
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 lPFmTl0V4jWa; Fri, 4 Sep 2009 12:52:48 -0700 (PDT)
Received: from looneymail-a3.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 3050A28C120; Fri, 4 Sep 2009 12:52:48 -0700 (PDT)
Received: from hixie.dreamhostps.com (hixie.dreamhost.com [208.113.210.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a3.g.dreamhost.com (Postfix) with ESMTP id B8E5C27B7E; Fri, 4 Sep 2009 12:51:30 -0700 (PDT)
Date: Fri, 04 Sep 2009 19:54:56 +0000
From: Ian Hickson <ian@hixie.ch>
To: 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>
In-Reply-To: <4D25F22093241741BC1D0EEBC2DBB1DA01AD6282C2@EX-SEA5-D.ant.amazon.com>
Message-ID: <Pine.LNX.4.62.0909041947250.26930@hixie.dreamhostps.com>
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>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
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 19:52:49 -0000

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.   `._.-(,_..'--(,_..'`-.;.'