draft-newman-comparator updated

Previous Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

draft-newman-comparator updated

Arnt Gulbrandsen

Hi,

the draft is lying silently in the internet-draft editor queue. However,
I would appreciate reviews, speedily if possible. If you have the time
and it isn't yet in your internet-drafts mirror, I can send a copy.

There are a few changes.

The basic and biggest change is that collation is defined in terms of
octet strings, with explicit notes that implementations may choose to
use character strings, and notes that in that case, e.g. i;octet may
not be possible to implement. Various minor changes changes result.

There are also more definitions and requirements. For example, equality
has to be implemented if ordering is, and if ordering returns equal,
equality must return true. That sort of thing.

I am unhappy with one thing: i;octet is still used a little as a last
resort to resolve equality/order, which brings it very close to
mandatory-to-implement. This doesn't seem necessary from an
architectural point of view. I just haven't found a solution I really
like.

Arnt

Reply | Threaded
Open this post in threaded view
|

Re: draft-newman-comparator updated

Martin J. Dürst

At 23:18 06/02/02, Arnt Gulbrandsen wrote:
 >
 >Hi,
 >
 >the draft is lying silently in the internet-draft editor queue. However,
I would appreciate reviews, speedily if possible. If you have the time and
it isn't yet in your internet-drafts mirror, I can send a copy.
 >
 >There are a few changes.
 >
 >The basic and biggest change is that collation is defined in terms of
octet strings, with explicit notes that implementations may choose to use
character strings, and notes that in that case, e.g. i;octet may not be
possible to implement. Various minor changes changes result.

This may work out, or it may not work out. I'll check this carefully,
but don't have any time this (and probably next) week, sorry.

The main problem is that octet-based collations (except possibly for
i;octet) need an encoding, but character-based collations obviously
don't. So if I have some French collation defined over characters,
and some French collation defined over iso-8859-1, how will they
be distinguished? How can we make sure registrations can be
as compact and easy as possible?

Regards,    Martin.


 >There are also more definitions and requirements. For example, equality
has to be implemented if ordering is, and if ordering returns equal,
equality must return true. That sort of thing.
 >
 >I am unhappy with one thing: i;octet is still used a little as a last
resort to resolve equality/order, which brings it very close to
mandatory-to-implement. This doesn't seem necessary from an architectural
point of view. I just haven't found a solution I really like.
 >
 >Arnt
 >