Subject: Re: Proposed amendment to language of draft-ietf-url-procedures

From: Ian King <[email-masked]>
Date: Mon, 13 Sep 1999 09:22:37 -0700

And what we are attempting to do, sir, is to provide the process for an IANA
registry -- in such a manner that does not create the frenetic free-for-all
we've seen in DNS.  (I trust you are aware that the DNS situation is
considered a "problem".)

I will not address your other comments.  I am always open to constructive
suggestions on how to solve the problems within this Working Group's scope.

Ian King <[email-masked]>
Quality Assurance, Speech Product Group
Intelligent Interface Technologies
MICROSOFT CORPORATION

-----Original Message-----
From: Masataka Ohta [mailto:[email-masked]]
Sent: Monday, September 13, 1999 12:21 AM
To: Ian King
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: Proposed amendment to language of draft-ietf-url-procedures

Ian;

> Then what do you suggest to provide collision management, identification
and
> interoperability in URL schemes?

Huh?

How, do you think, IANA is managing collisons, identifications
and interoperability of TCP port numbers?

> If you feel you have a viable alternative, that would prevent namespace
> collision, encourage development of interoperable standards, and provide
> sensible management of this highly visible namespace

DNS has a purely technical mechanism to enforce unique assignment
through well known single set of root servers, even which can be
ignored by local conventions.

URL does not.

> -- I'm all ears.

You only have to see the real world.

> But a lot of very intelligent folks have discussed
> this matter for a long time, and this is what they came up with.

You seems to have a very strange definition of intelligence.

                                                        Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 14 Sep 1999 08:31:50 JST

Ian;

How, do you think, IANA is managing collisons, identifications
and interoperability of TCP port numbers free-for-all?

> > interoperability in URL schemes?

DNS situation has no "problem" with regard to collision management,
identifiation nor interoperability.

Moreover, URL name space has nothing to do with that of DNS.

> suggestions on how to solve the problems within this Working Group's scope.

You seems to be believing that disbanding or rechartering of an WG
is destructive and is not an appropriate topic for the WG, which is
wrong.

That the working group scope is bogus is the constructive suggestion
for the internet protocol suites and is an appropriate topic for the
working group.

                                                        Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 15 Sep 1999 20:49:17 JST

I received a private mail from Ian, which contains no answer or

> and interoperability of TCP port numbers free-for-all?

His mail, instead, basically said that URL registration procedure
must exist because IETF once decided that URL WG should exist.

This is a bogus reasoning as we all know that IETF in not infallible.

                                                        Masataka Ohta

PS

Those who are interested in the exact content of Ian's mail should ask me
or Ian privately, not to infringe Ian's copyright.

---

From: Larry Masinter <[email-masked]>
Date: Thu, 16 Sep 1999 15:25:08 PDT

> > and interoperability of TCP port numbers free-for-all?

Don't rhetorical questions deserve rhetorical answers?

RFC 2434 (BCP 26) identifies several different ways in which name
and number spaces may be managed by IANA, depending on the
characteristics of the name space. "port numbers" and "URI scheme
names" have different characteristics and require different
management procedures.

I cannot tell if you are disputing RFC 2434 as a best current
practice or if you believe that port numbers and URI scheme
names are so similar in characteristics as a name space that
they deserve equivalent registration procedures (ask IANA
for a URI scheme name, and IANA assigns the 'next' one?)

Larry
--
http://www.parc.xerox.com/masinter

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 17 Sep 1999 08:39:06 JST

Larry;

> Don't rhetorical questions deserve rhetorical answers?

It is merely that your rhetorical answer to my essential question
is the victim of rhetorical counter-argument.

That's fine. But, mine is

> for a URI scheme name, and IANA assigns the 'next' one?)

If your argument, like Ian's one that URLREG WG does exist with
charters, assume the infallibility of IETF, it is bogus.

RFC 2434, of course, is wrong. Longer bits for a name space, a lot
longer than port number ones, merely means less conflict and control
regardless of whether you interpret it numbers or ASCII characters.

                                                Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 20 Sep 1999 12:59:58 JST

Larry;

> and number spaces may be managed by IANA, depending on the

This should be RCP 26.

INTERNET DRAFT                                                   M. Ohta
draft-ohta-iana-registration-00.txt        Tokyo Institute of Technology
                                                          September 1999

             IANA Registration and the End to End Principle

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This memo describes what IANA registration means and does not mean.

1. IANA registration

   Various protocols have fields values in which must be interpreted
   equally by all the parties of communications.

   To promote better interoperability, IANA is the place, recognized by
   those who developed the protocols, to register interpretations of
   various values of the protocol fields.

   IANA assigns unique values and make lists of the assigned values and
   their meaning with references to more detailed information.

   However, IANA registration does not mean that IANA provides collision
   management nor automatic identification of the registered values. The
   registration, either, does not assure the interoperability of the
   protocols.

M. Ohta                Expires on March 15, 2000                [Page 1]

INTERNET DRAFT             IANA Registration              September 1999

   IANA assignment of values, neither, overrides any intellectual
   property rights such as trademark or copyright.

   The Internet works based on the end to end principle [ARCH] that,
   parties, that is, end systems or hosts, of a communication are
   required to have an interpretation of values common only to them.
   The interpretation may be different from that registered to IANA.

   As such, when many or most hosts in the Internet share an
   interpretation of protocol values, some protocol fields have defact
   interpretations different from IANA registered ones.

   Because of the end to end principle, there, principally, can be no
   mechanism to enforce IANA registrations.

   It should be noted that the argument above is not applicable to
   values to identify end systems, namely, IP addresses and domain
   names. IP addresses are essential to routers while domain names offer
   a lot more human friendly identification.

2. IANA Assignments of IP Addresses

   Of course, some community can use IP addresses not authorized by
   IANA.

   However, end systems in the community can not be reached through the
   Internetworking layer from the Internet.

   The IP network of the community is isolated from the Internet, a
   loosely coupled collection of ISPs, which respect address assignments
   by IANA.

   Because of the global connectivity principle of the Internetworking
   layer, end systems must have globally unique IP addresses for global
   communication.

   The whole routing system of the Internet is the enforcement mechanism
   of IANA IP address assignment.

3. IANA Assignments of Domain Names

   The enforcement mechanism of IANA domain name assignment is DNS [DNS]
   tree rooted by set of root name servers, IP addresses of which are
   recognized by IANA.

   The DNS maintains the IANA name space of tree shaped realtime
   database of domain names, relying on the name servers identified by
   IP addresses.

M. Ohta                Expires on March 15, 2000                [Page 2]

INTERNET DRAFT             IANA Registration              September 1999

   Most of the hosts in the Internet use the name space.

   Most of the hosts in the Internet does not use other name spaces.

   Of course, a host does not have to be registered in the name space.

   The host may be registered in some name space other than that of
   IANA.

   However, most of the hosts in the Internet can not refer the host
   using domain name, which means that the host is isolated from the
   Internet from human perspective.

   Thus, most of the hosts in the Internet are registered to the name
   space of IANA.

4. References

   [ARCH] RFC1958.

   [DNS] RFC 1034, RFC 1035.

5. Security Considerations

   It should be noted that security, in general, is an end to end issue
   that arguments in section 1 is applicable to security related values.

   Authentication of identification can be performed end to end after
   end systems are identified by possibly insecure IP addresses or
   domain names.

6. Author's Address

   Masataka Ohta
   Tokyo Institute of Technology
   2-12-1, O-okayama, Meguro-ku,
   Tokyo 152, JAPAN

   Phone: +81-3-5499-7084
   Fax: +81-3-3729-1940
   EMail: [email-masked]

M. Ohta                Expires on March 15, 2000                [Page 3]