- From: Frank Ellermann <nobody@xyzzy.claranet.de>
- Date: Thu, 26 Jun 2008 22:36:37 +0200
- To: uri@w3.org
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