Subject: IANA, DNS names, URL names...

From: Masataka Ohta <[email-masked]>
Date: Tue, 28 Sep 99 5:39:45 JST

It basically says URLREG WG, which sees DNS and URL name spaces share
the same property, merely because they are string based.

Comments please.

						Masataka Ohta

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]

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 28 Sep 99 6:02:12 JST

I wrote;

> the same property, merely because they are string based.

I mean what the URLREG WG is doing is pointless.

						Masataka Ohta

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 28 Sep 1999 12:10:22 +0200

>the same property, merely because they are string based.

1) Your draft does not mention the URL name space
2) I don't see the relevance of URLREG to DNSOP and namedroppers
3) I disagree with you that URL scheme registration is pointless.
4) The same argument (if I understand it) applies to well known port numbers,
    protocol numbers and most other IANA registries. Do you think these
    functions too are pointless?

What's your point?

                      Harald A

--
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 29 Sep 99 8:19:14 JST

Harald;

>     protocol numbers and most other IANA registries.

Yup.

> 1) Your draft does not mention the URL name space

Of course. URL name space is no special that it is not necessary to mention.

>     functions too are pointless?

It seems to me that you are saying that registration of URL names shoule be
identical to that of well known port numbers and most other IANA registries.

I agree with you, then.

> 3) I disagree with you that URL scheme registration is pointless.

URL scheme registration is fine.

URL scheme registration scheme, which is totally different from that of
well known port numbers, is pointless.

> What's your point?

URLREG WG is pointless.

We don't need TCPPORTREG WG.

							Masataka Ohta

---

From: Tom Limoncelli <[email-masked]>
Date: Tue, 28 Sep 1999 21:44:55 -0400

Masataka-san,

Another summary of your RFC is:
	"The only real 'policy police' of the internet is end-to-end connectivity."

However, it is not clear what we are to infer from this.  Your statement "URLREG
WG is useless" made on this mailing list isn't a clear conclusion.  One might
also conclude "IANA must be extended to support the registration of <scheme>
strings so conflicts are not created."  That would be the opposite conclusion
that you wanted to elicit.

When I read your RFC I thought my mail reader had accidentally deleted the last
paragraph where you make such a statement.

My other field is activism.  From that field I learned a good formula for
certain statements is: "Educate, opinionate, activate".  That is, "Here is an
issue and the two viewpoints.  Here is why my voicepoint is right.  Here's what
you can do to to support this viewpoint."  Your RFC only makes the first portion
clear.

--Tom Limoncelli

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 29 Sep 99 11:04:41 JST

Tom;

> WG is useless" made on this mailing list isn't a clear conclusion. 

FYI, just recently, there was a pointless discussion on "tv" URL in
IETF list.

People in URL WG seemingly think URL names something special.

> One might
> strings so conflicts are not created."

That's not against my point.

							Masataka Ohta

---

From: Tom Limoncelli <[email-masked]>
Date: Tue, 28 Sep 1999 23:33:35 -0400

> FYI, just recently, there was a pointless discussion on "tv" URL in

Industries seem to put a lot of value on having a <scheme> named after them.  We
shouldn't forget this.

Every year I have to write a report to my boss of my accomplishments.  Most
people do.  Which would look better:
	I invented the tv:// syntax!!!
or
	I utilized existing syntax to make a workable solution to specify
	television channels in the URL namespace.

The first one serves a person.  The second one serves the community.  The former
must be discouraged; the latter must be encouraged.  My initial reading of the
URLREG drafts suggests that they would discourage the former but do nothing to
encourage the latter.

--tal

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 30 Sep 99 6:50:16 JST

Tom;

> Industries seem to put a lot of value on having a <scheme> named after them.
> We shouldn't forget this.

And we should not be involved with them.

> The first one serves a person.  The second one serves the community.

Your report to your boss serves the person, you, not the community.
regardless of whatever style you might use.

> The former must be discouraged; the latter must be encouraged.

While I can't understand the reasoning, it's OK if you don't
write any report to your boss of your accomplishments.

						Masataka Ohta

---

From: Randy Bush <[email-masked]>
Date: Wed, 29 Sep 1999 15:16:43 -0700

> 	television channels in the URL namespace.

the latter at any company at which i would wish to work or from whom i would
prefer to buy products.

randy

---

From: Tom Limoncelli <[email-masked]>
Date: Wed, 29 Sep 1999 18:42:46 -0400

> the latter at any company at which i would wish to work or from whom i would

I didn't mean to imply which my company is, by the way.  I'm just stating
how I think industries think, and that we should find a way to reverse
the trend.

First it was cool to be on the internet.
Then it was cool to have a domain.
Now its cool to have a protocol.
Soon it will be cool to have your own URL <scheme>.

Stop the world... I want to get off!

-tal

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Fri, 1 Oct 1999 12:31:24 -0400

I am having difficulty following this discussion.

>From where I stand the biggest problem is overloading of existing protocols
(particularly HTTP) for purposes far from the original design intent. A
large part of the motivation for this behaviour being to circumvent
corporate firewall restrictions.

Code re-use and specification re-use is a good thing - but only up to a
point. If the principle 'never create a new protocol if an old one will
serve' had been applied then HTTP would never have been invented since it is
_possible_ to do everything that can be done with HTTP with FTP, albeit in a
considerably less efficient manner (and I speak as someone who has
implemented both protocols and can give the number of IP round trips
required in both cases).

The basic structure of a URL is how://where/what. All three components serve
a different function. One does not re-invent how without good reason.

URIs, which are a superset of URLs and URNs also have the same structure,
albeit the syntax in use clearly differs from that proposed in various
'experimental' RFCs. This is one of those cases where certain folk have had
very definite views on the syntax. VERY VERY definite views, but which have
lacked any explanation which is why I suspect they have been ignored.

It appears to me that the tv scheme is really a URN scheme rather than a URL
scheme. There is considerable utility in a naming mechanism which allows
resources to be identified, even if it is not possible to retrieve them.

Unfortunately I do not see any means of resolving the issue at this stage.
The URN working group proposed a syntax that bears no relation to the URL
syntax and introduced spurious 'requirements' that had no justification
(actually they might have had a justification but people steadfastly refused
to ever give me one, for seven years I have been told "that was decided
before you arrived" and "It is too late to change that now, we have to
finish in 3 months").

In short I don't think the IETF need argue about the matter any further
because people trying to build stuff in the real world have long since
learned to ignore the IETF working groups claiming 'ownership' of the area.

		Phill