W3C home > Mailing lists > Public > public-ietf-collation@w3.org > October 2004

draft-newman-i18n-comparator: issue chars-or-octets-06

From: Martin Duerst <duerst@w3.org>
Date: Tue, 19 Oct 2004 15:48:52 +0900
Message-Id: <>
To: "Michael Kay" <mhk@mhk.me.uk>, <public-ietf-collation@w3.org>

Hello Michael, Jim,

Many thanks for your comments. Sorry to be late with responding.

I'm going to reply to your mails separately for each issue.

At 19:11 04/08/24, Michael Kay wrote:
 >Some comments on the draft:
 >(a) I think we should be defining a function on character strings, not on
 >octet strings. The encoding of the strings is a matter for the protocol to
 >negotiate, and the protocol should be out of scope for this document. (By
 >"character string", I mean a list of integers being the Unicode codepoints).

I have assigned this issue chars-or-octets-06

It seems that some protocols (ACAP? experts, please help) are using
UTF-8 only, but then they also want to have a 'binary' sort order,
for cases where the UTF-8 data might not be clean (or maybe also for
binary data?).

In my view, there is quite a bit of description in the draft that
can be cleaned up, and I'll work on that. Overall, the draft should
probably leave open the possibility of using an octet collation,
but a protocol should expliticly have to declare that it is using
that, the default should be characters only.

I'm wondering how important the possibility to register additional
'octet' collations is; there is currently only one, and it's difficult
to imagine needing more (unless we would want one for UTF-16).
So most probably, we can declare the 'octet collation' to be a
very special, one-of-a-kind case that has to be explicitly invoked.

Regards,     Martin. 
Received on Tuesday, 19 October 2004 06:54:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:38:40 UTC