Re: Error handling in URIs

Felix Sasaki wrote:

> http://lists.w3.org/Archives/Public/www-tag/2008Jun/0110.html
[...]
> the above link points to an approach of not munging IRI and
> URI, but making the difference clear.

That's not how I interpret "extended".  I'm sorry to note it,
but when the word "extend" already gets me in full combat
mode then something else in this mail doesn't help.  Quoting
RFC 3987, fifth statement in the abstract on page one:

| The approach of defining a new protocol element was chosen
| instead of extending or changing the definition of URIs. 
  ^^^^^^^^^^^^^^^^^^^^
IMO anything else would not be published on standards track 
without IAB review.  

> different communities have established different terminology.

Sure, I didn't doubt that such newspeak has a purpose, but it
is hostile to users.  They will upgrade their OS and browsers
when they are ready for it.  Not because the browser industry
redefines the term URL, and then claims that it is the fault
of the users if their old software "only" implements STD 66.

> See also Henry's mail

I'm fine with saying "URL" colloquially, outside of standards,
also for IRIs.  And at some distant point in the future all
technical IRI, TUS, UTF-8, NFKC, IDNA, and punycode details
will be hidden in APIs available everywhere.  But that's not
yet the case.

> there are many other communities interested in identifiers,
> and often the terminology is a mess.

ACK.  But making it worse is not a good idea.  It results in
vague ideas such as "any Unicode string is an IRI".  Maybe I
missed some points, but my impression was that they actually
want an <isegment> or <ipath> in ECMA 376.  That is simple
under the <ucschar> limitations in the IRI-bis draft, or the
similar <ucschar> in RFC 3987.  

 Frank

Received on Thursday, 26 June 2008 20:35:42 UTC