Re: [idn] A two-level problem?

[James Seng <jseng@pobox.org.sg>]

Original I thought the discussion would go that way too. This is why up to
v0.3 I have sections on Client/Server/Zone requirements. However the discuss
never go in that direction and these sections remain empty from 0.1 to 0.3. 

Therefore, I will pull it out of the next version. Will put it back if there
are specifics requirement to transport or server (or client).

-James Seng

Harald Tveit Alvestrand wrote:
> 
> In reading all these messages, I wonder if we're getting too close to the
> problem.
> We're discussing DNS modification, character set representation and so on
> as an unit; I wonder if it would be good to pull back a little and see if
> the problem admits of subdivision.
> 
> For instance, if we imagine that the DNS service (as contemplated here)
> consists of 2 parts:
> 
> - The DNS transport, which is the part that goes from the client's interface
>    card to an authoritative server's interface card, including any caches on
>    the way, but NOT including what's inside client libraries or master servers
>    (indeed also excluding the zone transfer function; more later)
> 
> - The DNS service, which is the part that goes from the client application
>    program to the information that is published by the zone master.
> 
> The DNS transport can, I think, be described in fairly simple terms, such
> as:
> 
> - Binary-transparent movement of labels and record values; labels are
>    divided into pieces of up to 63 octets, and represented in length+value
>    format; forget about dot notation - it does not exist at this layer.
> - Well known cache matching rules; match on octet values, fold octets
>    0x41 to 0x5A to 0x61 to 0x7A for matching by caches, otherwise exact
>    match only
> - Only records from authoritative servers ever exist anywhere, and not a
>    bit gets changed in them (crucial for DNSSEC)
> 
> This should be only minor or no mods to the existing DNS service, and gets
> us out of the business of trying to do solutions that depend on
> intermediate-server upgrades (I hope!)
> 
> The DNS service layer is where we have the requirements; this is where one
> can talk about what *authoritative servers* are expected to match up, such
> as UTR#21 version 1, 2 or 3 or simple case folding or.....
> 
> When we're dealing with stuff that is this complex, it's almost certain
> that we have to change it later; if we can split up the model in such a way
> that it's clear that those changes impact *only* the DNS service layer, not
> the transport, then I think we have won a great deal.
> 
> And if we can get this conceptual model described in the requirements
> document, I think we can lay to rest a good deal of the worries of some
> people for the operational impact of IDN.
> 
> Just a thought and an idea - if it's right, we should be able to worry more
> constructively.
> 
> What do you think?
> 
>                    Harald
> 
> --
> Harald Tveit Alvestrand, EDB Maxware, Norway
> Harald.Alvestrand@edb.maxware.no