To: uri@bunyip.com
Subject: Misc Comments
In-Reply-To: Your message of Wed, 13 Apr 1994 17:56:08 -0700.
<94Apr13.175608pdt.2760@golden.parc.xerox.com>
Date: Sat, 16 Apr 1994 23:13:31 -0400
From: John Curran <jcurran@nic.near.net>
Message-Id: <9404162314.aa28866@nic.near.net>
--------
] From: Larry Masinter <masinter@parc.xerox.com>
] Subject: Re: URL requrements: Structure in string
] Date: Wed, 13 Apr 1994 17:56:08 PDT
]> (Tim BL)
]> You may be in a minority, but you certainly aren't a minority of one. I and
]> a few others did try to defend the existing URL interpretation of / and ? on
]> this list before the Seattle meeting. However, it appears that none of us
]> were able to be in Seattle, so we were a flesh minority. It's ironic that
]> the "final" decisions on controversial issues for technologies that aspire
]> to replace physical contacts with virtual ones are made at physical
]> meetings. It's a bandwidth issue, I guess.
]
] Actually, I don't think this is the case at all. Final decisions are
] not made at the meeting, final decisions are made at the net. We've
] had ample opportunity to discuss / vs ? vs other things on the list,
] we've gone through the issues, looked at the pros and cons of treating
] URLs as interpreted strings vs. non-interpreted strings, and made some
] decisions.
As a friendly reminder:
RFC's (even those on the standard track) are subject to revision
as our understanding of the problem changes. "Final decisions"
are reached by having both standards-track specifications and
significant implementation experience.
Other disjoint miscellaneous comments:
o I would not be fond of a complex URN->URL resolution protocol.
I really couldn't care less whether it runs over UDP, RDP, TCP
or something else; it's just important that all applications can
readily make use of such functionality, just as many applications
make use of DNS today. If someone can write a *small* subroutine
library that does URN resolution via HTTP, Prospero, or DCE then
great. If such libraries can't be readily provided, then we need
a lighter protocol.
o LIFN's for "byte-stream" identification is very important. Shouldn't
it be possible to now define an "MD5" namespace authority via an
informational RFC which specifies how to calculate the defacto name
of any byte-stream?
o Redundant (and potentially load-leveling) servers will be required for
any resolution service. There's nothing wrong with using DNS for
finding the appropriate URN-resolution-servers, but please do not use
DNS as a resolution mechanism itself since the existing DNS hierarchy
will not easily reflect the "named information" hierarchy and has been
designed with a particular data model in mind which UR* objects may
not fit.
/John