Re: iDNR, an alternative name resolution protocol

Larry Masinter (masinter@parc.xerox.com)
Tue, 1 Sep 1998 20:47:45 PDT


From: "Larry Masinter" <masinter@parc.xerox.com>
To: "Sam Sun" <ssun@CNRI.Reston.VA.US>
Cc: "URI distribution list" <uri@Bunyip.Com>
Date: Tue, 1 Sep 1998 20:47:45 PDT
Message-ID: <001601bdd624$71f525a0$15d0000d@copper-208.parc.xerox.com>
In-Reply-To: <001f01bdd5e7$d55c4e80$1c1e1b0a@ssun.CNRI.Reston.Va.US>
Subject: RE: iDNR, an alternative name resolution protocol

> The draft defines URI as "... both for transmission in network protocols and
> representation in spoken and written human communication".

No, RFC 2396 defines URIs. This draft merely summarizes it.

> However, it seems
> that the URI defined for network protocol may have different set of
> requirements from URI targeted for human communication.

Different requirements are placed on URIs by each context, but there is an
overriding
requirement for a single kind of identifier which is useful in both contexts.


> URI defined for
> network protocol doesn't need to be concerned with "user friendly" as much
> as URI defined for human comsumption.

No, because there is a frequent transport between the two.


> And I think URI defined human
> communication should not require "everyone in the world be able to read or
> enter", because no single language is "friendly" to everyone in the world.


There is no such requirement placed; you're not quoting from either rfc2396 or
draft-masinter-url-i18n.

> For any particular URI scheme defined for a specific network protocol (e.g.
> http), it makes it simpler to have a uniform encoding. However, if URI is
> defined as the guideline for every network protocol to be integrated with
> web browser, it doesn't seem practical to enforce any specific encoding.

It isn't practical to 'enforce', but it is practical to 'encourage', and this
draft lays out how to
do so for one specific encoding. If you don't think it's practical, you need to
support that
assertion.


> Different URI schemes may map to different network protocols, and different
> protocols may have their very own encoding (already) defined.

Then they won't use this method.

> In fact, most
> URI scheme specific Resolver (telnet, ftp, ldap, ...) treats its URI as
> "human entered" and converts it into the protocol encoding before sending
> out the request.


The draft gives specific recommendations for URI interpreting software, which
includes
"URI scheme specific Resolver". You are describing the current state, which I
believe
is acknowledged.
>
> These said, it seems more appropriate to define URI "for representation in
> spoken and written human communication" ONLY.

It is inappropriate, because URIs are used in both roles.

> And the URI encoding should be
> defined as scheme specific.

There is no advantage and much harm in pursuing that.

>Some URI schemes (e.g. "http:") may require a
> single encoding. While other URI schemes (e.g. "hld:") would allow any
> native encoding to be used.


This is discouraged in section 2.2.3 of the url guidelines draft, and I see no
reason
to withdraw that.

 The conversion from the human entered URI to the
> network protocol is handled by the scheme specific Resolver.


I understand how you would like this to read, but I haven't seen any
justification
for your position except that you have it.

Creating a uniform way of encoding typed characters into URIs as they are
entered
has an enormous advantage, in that it is likely to work and to allow users who
read
and write languages that are not ASCII to do so independent of the 'scheme' of
the
URI. This seems to be very powerful and useful in bringing coherence to the web.

Larry