RE: Compatibility requirements

[Andrew Draper <ADRAPER@altera.com>]

> 2.1 Backwards compatibility
> 
>      The same request should generate the same response, regardless of
>              ^ name resolution

Agree.

>      the location (or localisation settings) of the resolver, the master
>      server and any slave or caching servers involved.
> Are "master server" and "slave or caching servers" defined anywhere? If

Master server is defined in RFC 1034 section 4.3.5.
I can't find a definition of slave server in RFC1034, perhaps we should use
secondary instead since that means the same thing.
Caching server is a term in general use.  I can't find a definition for it.

Perhaps we should add the following to the conventions section:

A master server for a zone holds the main copy of that zone.  This is
sometimes stored in a zone file.  A slave server for a zone holds a complete
copy of the records within that zone.  A caching server holds temporary
copies of DNS records, it can use these records to answer identical queries
and thus reduce network traffic (as restricted by the TTL).

(Or perhaps this is too technical and we should just try and reference
someone else's definition)

> not, I think they should be removed. It is the job of the resolver to
> resolve the name the same regardless of the environment.

Yes, but we are defining requirements for the environment (the servers) as
well as for the resolver.

>      It should be possible to build a caching server which does not
>      understand the language set in which a request (or response) is
>      encoded, and which works as well for IDNs as in the ASCII-only
>      case.
> Again the question of the definition of a "caching server". Also,
> I have never seen the term "language set". I cannot understand what
> this requirement means; can we delete it or combine the meaning in
> the previous one?

Since this was derived from one of my requirements I have to confess that I
made up the term "language set".  What I meant this to mean was that a) if
we specify a protocol which uses language tagging those tags should be
opaque to a caching server and b) if we specify a canonicalisation algorithm
the caching server should perform correctly* regardless of how much (or how
little) of that algorithm it has implemented.

* A caching server performs correctly if it gives the essentially the same
answer as the master server would have done if presented with the same
request (ie apart from the authoritative bit).

> 4. Compatibility
> 
> This section should be part of 2.1.
> 
>      Total compatibility with all existing standards and software which
>      is related to domain names cannot be achieved.
> I don't like mixing "standards" and "software" in this sentence. There
> are proposals for internationalized DNS that maintain total compatibility
> with existing standards. Of course, none could be compatible with
> existing software. I propose that this be changed to "The best solution
> is one that maintains complete compatibility with current DNS standards
> as long as it meets the other requirements in this document."

Agree.  Total compatability with a wide range of software (including all the
undiscovered features in that software) is impossible.

[Text removed]

> There can be no "flag days" nor a split DNS.

Agree
 
> Adding internationalization should add no new centralized
> administration for the DNS. A domain administrator should be able to
> create internationalized names as easily as adding RFC 1035 names.

Agree