- From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
- Date: Fri, 02 Jan 2015 20:42:38 +0900
- 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