W3C home > Mailing lists > Public > public-iri@w3.org > December 2004

editorial change to draft-duerst-iri-11.txt

From: Martin Duerst <duerst@w3.org>
Date: Tue, 14 Dec 2004 16:20:47 +0900
Message-Id: <6.0.0.20.2.20041214161638.04b169a0@localhost>
To: public-iri@w3.org

This is just to keep everybody up to date:

In section 5.3.2.2, "Character Normalization" of draft-duerst-iri-11.txt,
there is a Note that contains some accidentally duplicated text.
Michel Suignard discovered the problem, and I have asked the RFC
editor to fix it before publication. Michel also pointed out that
some of the explanation about multiple choices,... may be difficult
to understand, but we have decided to not make any further changes
at this point.

As a result, the actual edit, in OLD/NEW notation for the RFC editor, is:

OLD
    Note: Because it is unknown how a particular sequence of characters
       is being treated with respect to character normalization, it would
       be inappropriate to allow third parties to normalize an IRI
       arbitrarily.  This does not contradict the recommendation that
       when a resource is created, its IRI should be as
       character-normalized as possible (i.e.  NFC or even NFKC).  This
       is similar to the upper-case/lower-case problems in
       character-normalized as possible (i.e.  NFC or even NFKC).  URIs.
       Some parts of a URI are case-insensitive (domain name).  For
       others, it is unclear whether they are case-sensitive or
       case-insensitive, or something in between (e.g.  case-sensitive,
       but if the wrong case is used, a multiple choice selection is
       provided instead of a direct negative result).  The best recipe is
       that the creator uses a reasonable capitalization, and when
       transferring the URI, that capitalization is never changed.

NEW
    Note: Because it is unknown how a particular sequence of characters
       is being treated with respect to character normalization, it would
       be inappropriate to allow third parties to normalize an IRI
       arbitrarily.  This does not contradict the recommendation that
       when a resource is created, its IRI should be as
       character-normalized as possible (i.e.  NFC or even NFKC).  This
       is similar to the upper-case/lower-case problems in URIs.
       Some parts of a URI are case-insensitive (domain name).  For
       others, it is unclear whether they are case-sensitive or
       case-insensitive, or something in between (e.g.  case-sensitive,
       but if the wrong case is used, a multiple choice selection is
       provided instead of a direct negative result).  The best recipe is
       that the creator uses a reasonable capitalization, and when
       transferring the URI, that capitalization is never changed.



Regards,    Martin. 
Received on Tuesday, 14 December 2004 07:20:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 April 2012 19:51:53 GMT