[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[idn] A two-level problem?
- To: idn@ops.ietf.org
- Subject: [idn] A two-level problem?
- From: Harald Tveit Alvestrand <Harald@Alvestrand.no>
- Date: Wed, 16 Feb 2000 13:48:14 +0100
- Delivery-date: Wed, 16 Feb 2000 04:44:56 -0800
- Envelope-to: idn-data@psg.com
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