RE: Some more possible requirements

[Andrew Draper <ADRAPER@altera.com>]

> > * Zone files should remain easily editable.
> 
> Yes, but what does that mean? Does 'easily editable' mean
> ASCII only? Does it mean a local encoding? Or what? What kind
> of editors/tools are you using or would be ready to use?

Thinking about it a bit more, this is very poorly expressed.  What I was
trying to say is that we shouldn't design something which makes me have to
use complicated tools to edit my zone files.  For example, if I have a text
editor which understands iso-8859-15 (or UNICODE, or ISCII, or whatever)
then I should be able to use that editor to produce zone files (providing my
DNS server understands them).  Not sure how well this works for languages
with  writing orders other than left->right though.

My main point here was about offline DNSSEC signing, where I want the signer
to output a zone file which looks similar to its input (same character set).
This allows me to check that the signer isn't doing anything funny, and as I
said before, will catch some administrative errors.  This argues *against*
ASCII only zone files.

> > * The spec should not make me pay registrars many times to 
> > register the same name.
> > 
> > Ie if I want banos.com I should not also have to pay for 
> BANOS.com (and all
> > the other permutations of upper and lower case if there is 
> more than one
> > non-ASCII character).  This implies that I should be able 
> to register some
> > sort of canonical form.
> > 
> > [In case my mail gets garbled, the third character of my 
> example is N-tilde]
> > 
> > This also holds when I am editing my internal zone files, 
> having a canonical
> > form will make my files smaller and easier to maintain.
> 
> For some cases, defining a canonical form is easy. For others, it may
> be too hard. In some cases, the borderline between a variant of a name
> that should be canonicalized and a different but similar name is not
> very clear. As an example, should banos.com be treated as an 
> equivalent
> of ban^os.com? (sorry, can't type a tilde on my keyboard) Should
> banos-ltd.com be treated as an eqivalent of banos.com?

Users have come to understand that, for ASCII, the DNS is case insensitive.
We should attempt to preserve that property. (This is a user level
requirement)

As an administrator I want the case insensitivity to be part of the protocol
so that I don't need to put two entries into my internal zone files.

Some character sets have different ways to represent the same character (for
example in UNICODE, the character n can be represented by code 00F1 or by
006E + 0303).  We should define the protocol in such a way that these
different representations are hidden from both users and administrators.

I think the requirement should be that if we can define a canonical form of
something then we should do so.  Referencing someone else's canonical form
definitions would probably be good if that is possible.

> What I can imagine in certain cases is that registrars offer to
> register CNAME/DNAME variants for a small price increase. Would
> that be acceptable?

I suspect that most registrars know less about the intricacies of character
set equivalence or canonicalisation than the people in this working group.
If we define canonicalisation in some fashion here then it will relieve them
of the need to do it on a case by case basis (inevitably getting some of
them wrong).  This will result in a better internet for everyone.

> > * An IDN capable resolver should not generate any more 
> traffic (for both IDN
> > and pure ASCII names) than a non IDN capable resolver.
> > 
> > This implies that there should be some sort of canonical 
> form which the
> > resolver can use for requests.
> 
> I would prefer that too, but it's not necessary. It may imply that the
> server does the canonicalization. I understand that that's what is
> currently done for case folding with ASCII.

Yes, you're right.  This only implies that the client *or* the server does
the canonicalisation.

I think the traffic requirement is very important though.

However, there is another issue which will affect this.  In order to
generate a similar amount of traffic we must not break the DNS caching
architecture.  So a caching server must generate the same response as an
origin server, which means that it must contain the same canonicalisation
algorithm (I can think of ways to make server canonicalisation work when the
algorithms differ but they're all horrible).  The same argument applies to
secondary servers (except that I can't think of ways to allow different
algorithms here).

Is it likely that the canonicalisation algorithm will change (for example as
new languages are added)?  If so then we need a requirement:

* The canonicalisation algorithm must be easily upgradable as new
languages/writing systems are added.

Regards,

    Andy