>>>>> On Tue, 6 Aug 2002 15:13:58 -0500, "Stephen Sprunk" <ssprunk@cisco.com> said:
>> Most notably, The DNS Notation Backwardsness.
Stephen> You'll note that JANET originally used the notation you refer to as "forwards"
Stephen> and it was decided that was a bad idea, and they joined the "backwards" notation
Stephen> crowd.
I spent a fair amount of time in early 1999 and
educated IETF cult's chiefs about
The DNS Notation Backwardsness Problem
The conclusion of that thread was that indeed
we have a genuine architectural DNS Notation Backwardsness
Problem. I included samples of acknowledgement of the
problem in my previous message. Was hoping by now
that would be enough.
Perhaps you have not been around long.
I don't feel like leading that educational
process on this list again. However, I am
attaching to this message a summary from the
January 1999 thread which adequately describes the
problem.
My thinking now, as it was in 1999, is that those who
insist on denying real problems can be left behind.
The key point now is that the effort that Stef is now
leading towards the natural parallel server clusters
evolution provides a unique opportunity towards
fixing the notation problem as well.
As we consider raising the DNS name space roof we have an
opportunity to deal with other aspects of the
DNS notation.
Despite previous failures of the IETF in dealing
with architectural problems, I'd like to think
that the clear nature of this opportunity to
fix the notational problem may resonate
with some in the Internet Technical Community
and result into a movement towards a
solution ... Perhaps along the lines that I suggested.
--- Original Jan 21 1999 DNS Backwards Notation Problem Description Follows ---
From: Mohsen BANAN <mohsen@neda.com>
To: Brian E Carpenter <brian@hursley.ibm.com>
Cc: ietf@ietf.org
Subject: Re: Now: Next Generation Domains and DNS -- Was: Re: No More Central Authority: Not NSI/ICAN! Not ORSC!
Date: Thu, 21 Jan 1999 22:41:13 -0800 (PST)
[This is a summary response which in addition
to Brian's message addresses others' related
comments.]
>>>>> On Thu, 21 Jan 1999 16:24:12 +0000, Brian E Carpenter <brian@hursley.ibm.com> said:
Brian> What I meant, and I think conveyed very accurately, is that
Brian> both computers and humans can parse strings in either direction,
Brian> so there is no "right" and "wrong". That being so, there is no
Brian> reason to change anything and introduce confusion.
>>>>> On Thu, 21 Jan 1999 21:20:14 +0400, Peter Dawson <peterdd@gto.net.om> said:
Peter> no doubt that computers parse in either directions..zats
Peter> because people programmed them to. ...
This is not about parsing of strings.
It is about a fundamental architectural design
decision. Based on what we have learned over
the past 15 years, the "right" and the
"wrong" are quite clear now.
Key architectural attributes for "right" and
"wrong" are consistency, uniformity, cohesion,
fitness in bigger pictures, usability, ...
These are not any "strings". Naming and
addressing are an integral part of the
architecture of any network. One of the
reasons why X.400 died is because its
addressing design was unworkable.
With a variety of methods, even in an
evolutionary way, we have an opportunity to
improve on the current Domain Notation situation.
Yes, we have a problem. Our notation for
Domains *IS* backwards. The first step is to
recognize and acknowledge that.
Brian, the fact that you, the Chair of
Internet Architecture Board, is denying the
existance of this architectural problem -- and
consider it a string parsing issue -- is quite
disturbing to me.
Let me try again and make the existance of the
problem more clear.
Right now Internet Domains don't fit right
with numbers and the rest of the user's
integrated environment.
Any time that numbers and Domains have to work
together, it becomes un-natural, inconsistent
and backwards. I call that "wrong".
Examples:
IP Addresses:
-------------
To find the name corresponding to
the IP address of your nameserver which
is: 194.196.110.155
I have to enter it backwards (wrong).
155.110.196.194.in-addr.arpa name = sp2tr5.hursley.ibm.com
In that case the natural (right) could have been.
arpa.in-addr.194.196.110.155
Fax Numbers:
------------
To send a fax to +1.888.555.2222 using say
tcp.int:
I have to put the numbers in backwards.
remote-printing.Name@2.2.2.2.5.5.5.8.8.8.1.tpc.int
Phone Numbers:
--------------
If the Domains were straight I could imaging
doing stuff like:
Call net.ByNumber.1.888.555.3333:voiceOverIP:"collect"
Can't do that with today's Domain Notation.
Let's go beyond numbers now.
Any time that anyone tries to use a consistent
mechanism for "completion", network objects
fail.
The file system guys got it right. The OS guys
got it right. The language guys got it
right. Us, the network guys, got it backwards!
I can't even try to use completion for URLs, I
can't use completion for email addresses,
can't ...
To me, "completion" is the ultimate test of
designing naming and addressing machinery.
Before people come back and say,
"Oh, this is not a network or a protocol
problem it is just a User Interface problem."
Let me say: If the protocol gets it wrong, in
practice the User Interface can't fix it.
There is no reason for not also fixing it at
the protocol level (evolutionary of course).
For example, the fact that no nslookup program
(that I know of) over the years have provided
a "straight" User Interface for in-addr says
something ...
As for the merits of mimicing the US Postal
Service. First let me point out that the
"backwardsness" problem goes beyond email
addresses and currently touches all service
identifiers.
More importantly to the extent that the
production of addresses on USPS envelops do
not involve a machine, for obvious reasons, the
drivers are human-to-human factors. Even then,
the human is expected to assist the machine
(in the US) with ZIP+4 numbers. ZIP+4 is the
man-machine part of the address. Now, ZIP+4
has the "right" order characteristics.
For example, my ZIP+4 is: 98008-5765. The
left most digits "98" correspond to the State
Of Washington. What is on the left is the
larger entity.
Now, if I want to use the Domain Notation to
set up a Physical Delivery Access Unit, then
the address would become something like:
Mohsen.Banan@5765.98008.ByZipCode.us
Again backwards!
You see, the USPS doesn't have much of a
problem here. Not much needs fixing there ...
To move the Internet forward, our Domain
Notation can benefit from some improvement.
Now, after all of this if there was to be an
acknowledgment that there is an architectural
problem here and that this is not a "strings
parsing" issue which can go either way, then
may be we can work on solutions ....
Or, we can just sweep known problems under the
rug.
Your Call!
us.ByZipCode.98008.5765@Mohsen.Banan