[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: address@hidden: [patch] url-hexify-string does not follow W3C spec]
From: |
YAMAMOTO Mitsuharu |
Subject: |
Re: address@hidden: [patch] url-hexify-string does not follow W3C spec] |
Date: |
Wed, 02 Aug 2006 11:06:27 +0900 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/22.0.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) |
>>>>> On 01 Aug 2006 10:47:07 -0400, Thien-Thi Nguyen <address@hidden> said:
> conversion to utf-8 is per the RFC, which seems to be the primary
> context for this function; avoiding that conversion means
> noncompliance w/ the RFC.
Do you mean RFC 3986 by "the RFC"? IIUC, it refers to UTF-8 in the
following 3 parts:
* 2.5 Identifying Data, 3rd paragraph
How to interpret a unreserved character as an octet. (It also
refers to other superset of the US-ASCII character encoding).
* 2.5 Identifying Data, last paragraph
Encoding of a URI component that represents *textual data*
consisting of characters from UCS for *a new URI scheme*.
* 3.2.2 Host
Encoding of a registered name that represents a host.
So, I don't think that avoiding UTF-8 conversion for non-textual data
or for a URI scheme that has existed as of RFC 3986 deviates from the
RFC.
YAMAMOTO Mitsuharu
address@hidden
- Re: address@hidden: [patch] url-hexify-string does not follow W3C spec], (continued)
Re: address@hidden: [patch] url-hexify-string does not follow W3C spec], Thien-Thi Nguyen, 2006/08/01
Re: address@hidden: [patch] url-hexify-string does not follow W3C spec],
YAMAMOTO Mitsuharu <=