Subject: I-D ACTION:draft-ietf-cnrp-03.txt

From: [email-masked]
Date: Tue, 20 Jun 2000 06:45:59 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Name Resolution Protocol Working Group of the IETF.

        Title           : CNRP PROTOCOL SPECIFICATION
        Author(s)       : N. Popp, M. Mealling, M. Moseley
        Filename        : draft-ietf-cnrp-03.txt
        Pages           : 32
        Date            : 19-Jun-00

Please send comments on this draft to [email-masked].
People often refer to things in the real world by a common name or
phrase, e.g., a trade name, company name, or a book title. These
names are sometimes easier for people to remember  and type than
URLs.  Furthermore, because of the limited syntax of URLs, companies
and individuals are finding that the ones that might be most
reasonable for their resources are being used elsewhere and so are
unavailable. For the purposes of this document, a 'common name' is a
word or a phrase, without imposed syntactic structure, that may be
associated with a resource.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-cnrp-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-cnrp-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        [email-masked].
In the body type:
        "FILE /internet-drafts/draft-ietf-cnrp-03.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: James Seng <[email-masked]>
Date: Fri, 23 Jun 2000 11:23:41 +0800

Section 3.4 Character Set.

The character set encoding of a common names is always UTF-8.

Specifically:
   o  Within an XML query or response, the common name is represented
      in UTF-8, WITHOUT any hex-encodings
...

On the other hand, standard XML representation of Unicode characters is in
hex-encoding. &#0xHHHH;

Is there any reason to be different and to put raw UTF-8 here in the XML?

-James Seng

---

From: "Martin J. Duerst" <[email-masked]>
Date: Fri, 23 Jun 2000 15:05:07 +0900

>On the other hand, standard XML representation of Unicode characters is in

What you use above is called numeric character references.
Correctly, it's &#xHHHH;, not &#0xHHHH;

It is true that this is standard XML syntax, so every XML
parser has to understand it, and I would consider any spec
that ruled out numeric character references (which it looks
like the CNRP spec might do) as clearly suboptimal. About
the same as if you would specify that it's XML, but that
attributes always need single quotes, and never double
quotes. If this can be corrected, it should be corrected.
The same applies for decimal numeric character references
(&#ddddd;).

HOWEVER, it is not true that 'standard XML representation
of Unicode characters is hex-encoding'. Numeric character
references are an escape hatch, nothing else. Indeed the
default encoding for XML is UTF-8.

http://www.w3.org/TR/REC-xml#charsets:
All XML processors must accept the UTF-8 and UTF-16 encodings of 10646;

http://www.w3.org/TR/REC-xml#charencoding
Each external parsed entity in an XML document may use a different
encoding for its characters. All XML processors must be able to read
entities in either UTF-8 or UTF-16.
Entities encoded in UTF-16 must begin with the Byte Order Mark
described by ISO/IEC 10646 Annex E and Unicode Appendix B (the
ZERO WIDTH NO-BREAK SPACE character, #xFEFF). This is an encoding
signature, not part of either the markup or the character data of
the XML document. XML processors must be able to use this character
to differentiate between UTF-8 and UTF-16 encoded documents.
Although an XML processor is required to read only entities in the
UTF-8 and UTF-16 encodings, it is recognized that other encodings are
used around the world, and it may be desired for XML processors to
read entities that use them. Parsed entities which are stored in an
encoding other than UTF-8 or UTF-16 must begin with a text declaration

>Is there any reason to be different and to put raw UTF-8 here in the XML?

There may be a need to fix something, but using UTF-8 for XML
is just the most straightforward thing one can do, and there
is no reason to change this.

Regards,   Martin.

---

From: James Seng <[email-masked]>
Date: Mon, 26 Jun 2000 12:06:47 +0800

Martin,

Couldnt disagreed with you since you are definately the expert in XML :)

If this is the case, then rather than having Section 3.4 Character Set,
is it possible that this section refers to http://www.w3.org/TR/REC-xml
directly instead? Seem that this will make it more compilence to UTF-8, UTF-16
and hex-encoding notation.

Aside, I know of at least one XML parser which is definately not UTF-8 or
UTF-16 complience.

-James Seng

---

From: "Martin J. Duerst" <[email-masked]>
Date: Mon, 26 Jun 2000 13:56:33 +0900

>and hex-encoding notation.

Well, the CNRP WG apparently wanted to simplify things by only
using UTF-8 in the protocol. Just referencing the XML Recommendation
would change that, and the WG would have to decide.

>Aside, I know of at least one XML parser which is definately not UTF-8 or

Well, then it's simply not an XML parser, even if it may try to
look like one. By the way, which one is that?

Regards,    Martin.

---

From: James Seng <[email-masked]>
Date: Mon, 26 Jun 2000 22:31:17 +0800

> would change that, and the WG would have to decide.

Yea, I realised that after sending it *doh* or else we just point the whole
CNRP WG to XML ;)

But whatever the case, I find it seriously lacking information on I18N issues.
Having it just as 'just-send-UTF-8' is definately not good enough...

Thank god we haven't even got to canonicalization/normalization in UTF-8 :P

> look like one. By the way, which one is that?

From IBM.

-James Seng