- From: John C Klensin <john-ietf@jck.com>
- Date: Tue, 10 Jul 2012 14:20:48 -0400
- To: Julian Reschke <julian.reschke@gmx.de>, Peter Saint-Andre <stpeter@stpeter.im>
- cc: Dave Thaler <dthaler@microsoft.com>, public-iri@w3.org
--On Tuesday, July 10, 2012 20:09 +0200 Julian Reschke <julian.reschke@gmx.de> wrote: > On 2012-07-10 20:02, Peter Saint-Andre wrote: >> ... >> It seems to me that a browser does not need to present the >> "raw" URI in the address bar, and ought to display >> hex-encoded characters there in a > > s/characters/octets/ > > This is part of the problem :-) Yes, especially with UTF-8. And that is why I've been arguing for some years that the move from ISO 8859-1-friendly %hex encoding of octets to the basically user-hostile hex encoding of UTF-8 octets was a mistake that should not be propagated into something that is explicitly concerned with i18n. Note that, with %hex octet encoding of UTF-8, the typical user can't even tell where one character ends and another begins. \u(NNNN) and its variations isn't really user-friendly either, but at least it is about characters and can be mapped to a character (Unicode code point) by a single-stage lookup that doesn't require special programming. >> user-friendly manner. So I don't think that IRI vs. URI is >> all that relevant for the address bar, whereas it's more >> relevant for activities like authoring HTML documents. > > People paste from the address bar into href attributes. So > whatever works in the browser *will* end up in HTML documents. Yes. But, to the extent that is true and _all_ HTML implementations don't support IRIs in href arguments, Dave's assertion about IRI display in the address bar that started this thread leads to a failure condition. Again, I think the conclusion is that we need to do some careful rethinking here in a process that doesn't necessarily favor either of the present IRI or SIR ideas. best, john
Received on Tuesday, 10 July 2012 18:21:34 UTC