Re: Yet Another Attribute Parameter

Dirk.vanGulik@jrc.it Thu, 19 December 1996 08:17 UTC

Received: from cnri by ietf.org id aa25882; 19 Dec 96 3:17 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa04118; 19 Dec 96 3:17 EST
Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id DAA21945 for uri-out; Thu, 19 Dec 1996 03:04:02 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id DAA21939 for <uri@services.bunyip.com>; Thu, 19 Dec 1996 03:03:28 -0500
Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08593 (mail destined for uri@services.bunyip.com); Thu, 19 Dec 96 03:03:22 -0500
Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA08341; Thu, 19 Dec 96 09:07:36 +0100
Received: by jrc.it (5.x/EB-950213-L) id AA13453; Thu, 19 Dec 1996 09:00:43 +0100
Date: Thu, 19 Dec 1996 09:00:42 +0100 (MET)
From: Dirk.vanGulik@jrc.it
X-Sender: dirkx@elect6.jrc.it
To: Michael Mealling <michaelm@rwhois.net>
Cc: Larry Masinter <masinter@parc.xerox.com>, howes@netscape.com, ietf-asid@umich.edu, uri@bunyip.com
Subject: Re: Yet Another Attribute Parameter
In-Reply-To: <32B8066D.2A8D@rwhois.net>
Message-Id: <Pine.SOL.3.91.961219085532.11368N-100000@elect6.jrc.it>
Reply-Path: Dirk.vanGulik@jrc.it
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-uri@bunyip.com
Precedence: bulk


On Wed, 18 Dec 1996, Michael Mealling wrote:

> Larry Masinter wrote:
> > This is an issue for the new URL working group, to give guidelines on
> > what belongs in a URL and what doesn't, so I hope you don't mind if I
> > bring uri@bunyip.com into it. (The conversation should move to
> > ietf-url@imc.org as soon as that's created.)
> 
> I hope this won't take long since I'm sure several people are getting
> two copies of this thread....anyway.....
> 
> > Michael:
> > > In RWhois we are working on a UDP version. Several other protocols have
> > > both UDP and TCP connection styles. The problem is that URLs don't specify
> > > which service to use. ...
> > Tim:
> > > After thinking about this a bit, I think it makes more sense to
> > > include this information in the URL itself. A URL is supposed to be
> > > self-contained, including everything you need to know to access some
> > > resource. If the protocol you use runs over both TCP and UDP, there
> > > should be a way in the URL format to indicate which one (or not, if it
> > > doesn't matter).
> > 
> > The precedent hasn't really been that way. For example, 'ftp:' URLs
> > don't tell you the media type, and our attempt to make people use URLs
> > that tell you whether the remote file is text or binary has basically
> > failed.
> 
> That, among others, is why I didn't put it in the RWhois URL draft...
> 
> > If the protocol runs over both TCP and UDP, why not just say 'try UDP
> > and if it doesn't work, use TCP, and remember that UDP doesn't work to
> > that host'.
> 
> Primarily for the reason that if the UDP service doesn't exist then
> the poor user has to wait for some timeout period to expire before
> the TCP connection is tried.
> 
> > Is this acceptable? Is there any consensus on putting this guideline
> > into the URL process document?
> 
> I'd like some language on how to deal with timing out the UDP query
> so that the user doesn't wait to long just to find out if a service
> is available or not.
> 
> There is a solution but it requires the use of the SRV record which is
> not in widespread use yet....
> 

Actually one of the things we are using here internally are URL's of the
shape:

		srvq://some.f.q.d.n/opaque-string

To signal that the URL lookup/obtaining is to use an SRV query to work
out what protocol exist to obtain the resource. But to codify this
indirection, whilst keeping in line with the URL spec was beyond my
grasp of the subject as that spec seems very intent on one-step location;
issues like chaching and normalizing/specific instantces in different
protocols get really hairy. 

To be quite honest; the above really is a poor mans URN. So the UDP
version of protocols might want to wait for URNs to be there :-) 
(Shameless plug this is :-)

Dw.