# Misc Comments

John Curran (jcurran@nic.near.net)
Sat, 16 Apr 1994 23:13:31 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Karen R. Sollins: "URL requrements: Structure in string"
- Previous message: Alexander Dupuy: "MD5 and LIFNs (was: Misc Comments)"

    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

- Next message: Karen R. Sollins: "URL requrements: Structure in string"
- Previous message: Alexander Dupuy: "MD5 and LIFNs (was: Misc Comments)"