W3C home > Mailing lists > Public > public-ietf-w3c@w3.org > January 2015

Re: [url] Requests for Feedback (was Feedback from TPAC)

From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Date: Fri, 02 Jan 2015 20:42:38 +0900
Message-ID: <54A6842E.6080002@it.aoyama.ac.jp>
To: Sam Ruby <rubys@intertwingly.net>, Mark Nottingham <mnot@mnot.net>
CC: "public-ietf-w3c@w3.org" <public-ietf-w3c@w3.org>, Julian Reschke <julian.reschke@gmx.de>
Hello Sam, others,

On 2014/12/24 04:47, Sam Ruby wrote:

> 2) The URL LS is IDNA and Unicode more aware than RFC 3986 is.  Clearly,
> this is by design, but I will suggest that there is an important lesson
> to be learned by the effort to split out RFC 3987 into a separate RFC: I
> think that unintentionally had the effect of "ghettoizing" IRIs.

Having IRIs as a separate concept was (and probably still is) necessary 
because not all software and not all protocols are able/ready to accept 
non-ASCII characters.

Also, keeping IRIs as a separate concept but as a protocol elements was 
a compromise between those who wanted them only as an UI 'frontend' and 
those who wanted Unicode everywhere.

The URL spec, as far as I understand, allows Unicode as input, so in 
that respect, it isn't ghettoizing. But it converts all output to ASCII, 
and so essentially sends a message that Unicode is second-class.

My understanding is that the reason for this is that current browser 
interfaces are working that way, and I'm not against documenting that, 
but I'd wish we could get away from that limitation for the general case 
(i.e. parser results are still Unicode).


> I
> might be misreading Martin, but perhaps that's why he suggested RFC 3986
> errata as the way to handle bidi?[3]

It might be my fault, but you're definitely misreading me, because I 
never suggested that bidi could be handled as an erratum to RFC 3986.

Regards,   Martin.


> - Sam Ruby

> [3] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13516.html
Received on Friday, 2 January 2015 11:43:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:10:18 UTC