Re: [hybi] ws: and wss: schemes

[Ian Hickson <[e-mail]>]

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

Release early, release often. I always want community review.


> Is now a good moment to read it?

It's always 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.

My source file is an HTML document, so I don't think that would work well.


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

I've read this, but as far as I can tell, "Always UTF-8" and "See IRI" are 
both complete and accurate ways of addressing this.

Since apparently neither of these options satisfies you, could you state 
exactly what literal text would satisfy you?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'