headers
Ian Hickson | 4 Sep 2009 07:33
Picon

Re: ws: and wss: schemes

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?

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

> What's the effect? How are they used?

This is defined earlier in the Web Socket specification.

> PS: what does RFC5238 have to do with this?

Oops, typo. Fixed. (Meant 5234.)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joseph A Holsten | 4 Sep 2009 09:14
Gravatar

Re: [Uri-review] ws: and wss: schemes


On Sep 4, 2009, at 12:33 AM, 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?

URIs are not i18n-aware, you're thinking of IRIs. But since there is a  
standard mapping for IRIs, it's pretty clear what you actually want.  
The *URI* syntax should be:

   "ws" ":" heir-part [ "?" query ]

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 4 Sep 2009 19:00
Picon
Picon

Re: [hybi] ws: and wss: schemes

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.

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

>> What's the effect? How are they used?
> 
> This is defined earlier in the Web Socket specification.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Phillips, Addison | 4 Sep 2009 19:41
Picon
Favicon

RE: [hybi] ws: and wss: schemes

Hello uri <at> ,

[personal note, not representative of i18n wg]

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

I agree with Julian. If you are defining a URI syntax, you can't use IRI to do so. 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",
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Hickson | 4 Sep 2009 21:54
Picon

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...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kristof Zelechovski | 4 Sep 2009 22:05
Picon
Gravatar

Re: [hybi] ws: and wss: schemes

URI restrictions are not an anachronism.  Imagine an Englishman with no
knowledge of Japanese and no pocket translator to access a resource under a
Japanese IRI that he has printed on paper.  Good luck with that.
Best regards,
Chris

-----Original Message-----
From: uri-review-bounces <at> ietf.org [mailto:uri-review-bounces <at> ietf.org] On
Behalf Of Ian Hickson
Sent: Friday, September 04, 2009 9:55 PM
To: URI; hybi <at> ietf.org; uri-review <at> ietf.org; public-i18n-core <at> w3.org
Subject: Re: [Uri-review] [hybi] ws: and wss: schemes

> 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.
Permalink | Reply | 0 comments |
headers
Julian Reschke | 4 Sep 2009 22:05
Picon
Picon

Re: [hybi] ws: and wss: schemes

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Hickson | 4 Sep 2009 22:19
Picon

Re: [hybi] ws: and wss: schemes

On Fri, 4 Sep 2009, Julian Reschke wrote:
> 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.

That's what I thought, but then I got feedback saying I had to register an 
IRI scheme if I wanted to use IRIs.

I've no interest in making ws: and wss: URIs. Only IRIs.

If I define the syntax to be a subset of the full URI syntax, how does it 
ever get extended to be a subset of the full IRI syntax?

What should I put in the spec to make you happy and to make the use of ws: 
and wss: IRIs fully well-defined?

> > > > > 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...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joseph A Holsten | 5 Sep 2009 01:51
Gravatar

Re: [hybi] ws: and wss: schemes


On Sep 4, 2009, at 3:19 PM, Ian Hickson wrote:

> On Fri, 4 Sep 2009, Julian Reschke wrote:
>> 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.
>
> That's what I thought, but then I got feedback saying I had to  
> register an
> IRI scheme if I wanted to use IRIs.
>
> I've no interest in making ws: and wss: URIs. Only IRIs.
>
> If I define the syntax to be a subset of the full URI syntax, how  
> does it
> ever get extended to be a subset of the full IRI syntax?
>
> What should I put in the spec to make you happy and to make the use
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julian Reschke | 5 Sep 2009 08:43
Picon
Picon

Re: [hybi] ws: and wss: schemes

Ian Hickson wrote:
> ...
> That's what I thought, but then I got feedback saying I had to register an 
> IRI scheme if I wanted to use IRIs.
> 
> I've no interest in making ws: and wss: URIs. Only IRIs.
> 
> If I define the syntax to be a subset of the full URI syntax, how does it 
> ever get extended to be a subset of the full IRI syntax?
> 
> What should I put in the spec to make you happy and to make the use of ws: 
> and wss: IRIs fully well-defined?
> ...

The point is not to make me happy, but to do the right thing.

Just define a URI scheme; use of ws IRIs will be defined automatically 
in terms of RFC 3987 (IRI experts, please correct me if I'm wrong).

> ...
>> The RFC reference is immutable. Just paste the content in your source 
>> file, and change the anchor attribute value.
> 
> My source file is an HTML document, so I don't think that would work well.

The source file that you feed into xml2rfc is an XML file using the 
RFC2629bis syntax. You control that file. Put into it what you need.

> ...
> I've read this, but as far as I can tell, "Always UTF-8" and "See IRI" are
(Continue reading)

Permalink | Reply | 0 comments |

Gmane