Fw: (Re: iDNR, an alternative name resolution protocol)

Jon Davis (jdavis@inetinit.org)
Tue, 1 Sep 1998 10:41:10 -0700


Message-ID: <003801bdd5cf$b5fdd620$637a0118@c603887-a.ptbrg1.sfba.home.com>
From: "Jon Davis" <jdavis@inetinit.org>
To: "URI distribution list" <uri@Bunyip.Com>
Date: Tue, 1 Sep 1998 10:41:10 -0700
Subject: Fw: (Re: iDNR, an alternative name resolution protocol)

-----Original Message-----
From: Jon Davis <jdavis@inetinit.org>
To: Larry Masinter <masinter@parc.xerox.com>
Date: Tuesday, September 01, 1998 8:35 AM
Subject: Re: iDNR, an alternative name resolution protocol

Okay, I see your point, but there's a couple things.. First of all, iDNR
would only be used as implemented in the hostname, not in the resource path.
The concepts were derived from the understanding that the URL syntax was:

scheme://username:password@[host]:port/resource

.. or something along those lines, but where "host" was assumed to be a
hostname as defined as a) an IP address, b) a DNS name, or c) a WINS or
other similar type of hostname. In each of a, b, and c, the rule is the
same: no spaces or symbols, and the delimiter is always a ".".  This is why
this issue was brought up in the first place, as it puts a huge burden on
namespace flexibility.  My recommendation is that the RFC's should NOT
specify the format of "[host]", but specifically as "[host]" is defined in
the protocol used (a, b, or c).  In this way, not only iDNR but future
naming schemes can be used to identify the host, each with its own URI
rules.  This sounds itchy to me, though, and I am open to correction.

Second, as I mentioned in the origintal post, the delimited names in iDNR
should be trimmed.  For example, the iDNR hostname:
{   host;  subdomain with spaces       ;        domain  }
.. should be interpreted as:
{host;subdomain with spaces;domain}

>If you want to say that white space isn't significant, well, then
>you just have an alternative way of writing URLs, but the URI spec
>already suggests that white space be ignored in URIs in plain text.

Not a request, just a question: Can the URI spec be edited to state that
this be effective on all of the URI but the hostname, where the hostname--if
not a, b, or c, as described above--must be escaped with [x] grouping
symbols so that the URI can interpret it out?

For example, in the iDNR-based URL:

http://{host;domain}/resource.html

.. would be parsed as:
http://iDNR.host/resource.html
... or something like that, where "iDNR.host" is merely a pointer to the
original hostname.  This example would not represent an ideal
implementation, but the point is that the hostname is identified as an
"alternative" hostname and is thus clipped out.

Just thinking out loud.


Jon Davis


-----Original Message-----
From: Larry Masinter <masinter@parc.xerox.com>
To: Jon Davis <jdavis@inetinit.org>
Date: Tuesday, September 01, 1998 8:12 AM
Subject: RE: iDNR, an alternative name resolution protocol


>The difficulties with white space aren't primarily that it's
>hard to find the delimiter -- as you point out, you could just
>surround the URL with delimiters. There's no ambiguity in
><A HREF="http://big.server/This is my home page"> and most
>HTML interpreters will happily parse out the spaces.
>
>The issue is that a person would likely make a mistake
>transcribing
>
>    <http://www.myserver.dom/
>     this is my URL>
>
>and possibly treat it identically to
>
>    <http://www.myserver.dom/
>     this is my URL>
>
>even though the latter has no spaces at the end of the first line.
>(See! I bet you thought they were the same, too.).
>
>If you want to say that white space isn't significant, well, then
>you just have an alternative way of writing URLs, but the URI spec
>already suggests that white space be ignored in URIs in plain text.
>
>
>Larry
>--
>http://www.parc.xerox.com/masinter
>
>
>