Re: [idn] Requirements: sorting

[Patrik Fältström <paf@swip.net>]

--On 2000-02-06 18.09 +0800, James Seng <jseng@pobox.org.sg> wrote:

> How does the sorting works? Is it sufficient to sort by raw binary bit?

Yes.

> If so, do we case fold before sorting? where is sorting required?
>
> can someone who is more familiar with DNSSEC explain in more details why
> sorting is needed in it?

The sorting is needed for the NXT records, i.e. the records which tell
where "holes" are in the sorted list of records. When a query is made for a
record which doesn't exist in the zone, a signed NXT is returned which
indicates that the name doesn't exist.

Example, if we in a zone have:

example.zone.  IN A 192.168.0.1
fexample.zone. IN A 192.168.0.1

and nothing between these names after sorting.

Then the following record will be added at the process of signing the zone:

example.zone.  IN NXT fexample.zone.

If I ask for "ezample.zone.", then the NXT record above is returned which
indicates that nothing exists between example.zone. and fexample.zone.

So, any sorting is enough, as long as it is very well defined. It has
nothing to do with what we normally call sorting, which is locale dependent.

Regarding casing, the current implementation in bind only handles a-z0-9
and '-' (according to the tests I have done), and it upcase all labels
which might exist in both upper and lower casing, and all other labels are
downcased. That is what happens... I.e. if "aaa" and "AAA" exists, then
both RRs get "AAA" as name, while if "AAA" and "AAA exist, then the case is
preserved, and likewise when "aaa" and "aaa" exists. (Is Ed on this list?
If so, maybe you can explain how you implemented this in dns_signer?)

So, I would propose that the case folding that will be used in DNSSEC is
exactly the same algorithm which is used when doing matching (which in
"our" case also means eventual canonicalization). Sorting can then be
binary, and not at all have anything to do with anything else.

    Patrik