[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[idn] Versioning - why not
- To: email@example.com
- Subject: [idn] Versioning - why not
- From: Harald Tveit Alvestrand <firstname.lastname@example.org>
- Date: Wed, 13 Dec 2000 13:29:58 -0800
- Delivery-date: Wed, 13 Dec 2000 14:27:22 -0800
- Envelope-to: email@example.com
About the item on versioning in the ACE encoding in today's IDN meeting:
I do not think versioning indicators, either in the name or in the query,
is either beneficial or necessary.
To see why versioning in the name is not beneficial:
Consider the name <name1>.<name2>.example.com.
If version numbers were used, we would have:
Now, if the <name1> zone server entry program changes version:
This is no longer known to the zone server at <name2>, and will thus get no
If the <name1> zone tries to compensate for this by keeping v1 encoding for
the name2 component, we get
Stretching this a little further, we see that a client that knows both v1
and v2 will have to perform the following queries:
And, of course, a client that knows only v1 will see all the v2 names
simply disappear from the Internet.
Let's dig into a case analysis of what changes can easily be foreseen:
- v2 adds characters not allowed in v1.
Result: Newly registered names using those characters cannot be seen
by v1 clients.
- v2 forbids characters allowed in v1.
Result: v2 clients cannot see names that were entered using v1, but are
now illegal. The registration authority should remove them anyway.
- v2 has a different downcase or map from v1, resulting in a name being
encoded differently in v2 than in v1. This is the troublesome case.
Result: v2 clients will look for a different name than v1 clients.
- v1 and v2 are both registered, and point to the same info. No problem.
- v1 exists, v2 not. Same case as for forbidden characters.
- v2 exists, v1 not. Same case as for new characters.
- v1 and v2 both exist, and point to different info. I claim that this
is an administrative problem, not something nameprep can solve.
My contention is that in NONE of these cases will there be any useful
benefit to the users from having information about the table versions being
used transferred between client and server.
Harald Tveit Alvestrand, firstname.lastname@example.org
+47 41 44 29 94
Personal email: Harald@Alvestrand.no