Re: comments on draft-eastlake-cturi-01.txt

Hi,

I'ved added ietf-types to the cc list as I think people there will be
interested.

From:  Aaron Swartz <aswartz@swartzfam.com>
Date:  Sat, 20 Jan 2001 22:41:52 -0600
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
CC:  Larry Masinter <masinter@adobe.com>, <uri@w3.org>,
            <Donald.Eastlake@motorola.com>, Graham Klyne <GK@ninebynine.org>,
            Michael Mealling <michaelm@netsol.com>,
            Ted Hardie <hardie@equinix.com>
Message-ID:  <B68FC4AF.20A2C%aswartz@swartzfam.com>
In-Reply-To:  <200101190550.AAA0000031026@torque.pothole.com>

>Donald E. Eastlake 3rd <dee3@torque.pothole.com> wrote:
>
>>> What's wrong with the current system of URI mapping:
>>>  http://www.isi.edu/in-notes/iana/assignments/
>> IANA is more or less in the process of moving from isi.edu to
>> iana.org, an illustration of the instability of domain names.
>
>So then use iana.org -- we expect that this will be around for a while, no?

Who knows?  Mail from iana.org even today has Message-ID headers that
end with iana@icann.org.

>>> http://www.isi.edu/in-notes/iana/assignments/media-types/
>> 
>> There is no guarantee of this structure remaining the same and I don't
>> see why one would think you could design a structure that would
>> encompass all current and future IANA supervised protocol parameter
>> values. 
>
>You wouldn't have to -- you could create them (as subdirectories) as they
>were needed. (I think I'm missing something here... what do you mean?)

If you are going to put a domain name into a URI value of (or mapping
of the value of) a fundamenal protocol parameter, you don't usually
want the operational inflexibity of putting all the structure into
"subdirectories".  If you put more of it into subdomains, then DNS can
be used to delegate management if/when that is appropriate.

>> Using a domain name in a fundamental protocol parameter
>> encoding is basicly a bad idea except in some cases where the domain
>> name is in a part of the DNS name space specifically set aside for
>> that purpose. 
>
>Why? It's just a string. You suggest one string, I suggest another. It just
>so happens that my string has greater utility and meaning to many people at
>this point in time. If that meaning and utility go away at some point in the
>future, then both of our strings will be equally useful once again.

No, it is not just a string.  It is a syntactically correct
identification of a node in the global DNS namespace.  Grabbing URIs
that just happen to be useful for human lookup "at this point in time"
and making them the permanent mapping has only a trivial current
benefit and the strategy ignores the cost of repeatedly changing them
in the future and the injury to anyone who might take over the domain
name for a different purpose in the future.

Fundamental protocol mappings and constants get locked into read only
memory.  There used to be a root DNS server at the host A.ISI.EDU
(which was the host ISIA in the global hosts.txt befor DNS was
deployed).  But that machine was soon decomissioned and the A root
server moved elsewhere.  A couple of years ago, more than ten years
after ISIA had been decomissioned, a workstation was installed at the
same IP address as ISIA used to have been.  It immediately started
getting dozens of root zone zone transfer requests a second!

In fact, I can't see why, in the dynamic environment of the Internet,
you would mandate a particular organizational domain name in the URIs
for the mapping of the values of a protocol parameter, unless your
goal was to try to lock in that orgnaization and its name.  It is my
personal opinion that neither isi.edu nor iana.org particularly want
to get locked in when the locus of managemet of some protocol
parameter could get moved elsewhere.

>In other words, you have everything to gain and nothing to lose.

As above, I don't agree.

>>> Also, what's the point of making URIs into content types? Where would this
>>> be used?
>> To express the types of objects that have only a URI type label
>> originally defined in MIME contexts such as SMTP where only
>> Content-Type is permitted.
>
>Ahh, I see. You should really talk to the Content-Type: whatever+xml folks
>about this -- people keep asking them to use namespaces as content-types.
>Perhaps your system could solve this problem.

Perhaps some of them are on ietf-types which I've added to the cc list.

>-- 
>[ Aaron Swartz | me@aaronsw.com | http://www.aaronsw.com ]

Donald
===================================================================
 Donald E. Eastlake 3rd                    dee3@torque.pothole.com
 155 Beaver Streeet                         lde008@dma.isg.mot.com
 Milford, MA 01757 USA     +1 508-634-2066(h)   +1 508-261-5434(w)

Received on Sunday, 21 January 2001 22:09:10 UTC