Proposed revision of 1738 and possibly 1808

Larry Masinter <masinter@parc.xerox.com> Mon, 08 January 1996 07:36 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06116; 8 Jan 96 2:36 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06110; 8 Jan 96 2:36 EST
Received: from services.Bunyip.COM by CNRI.Reston.VA.US id aa02237; 8 Jan 96 2:36 EST
Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id CAA23171 for uri-out; Mon, 8 Jan 1996 02:24:41 -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 CAA23166 for <uri@services.bunyip.com>; Mon, 8 Jan 1996 02:24:38 -0500
Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06918 (mail destined for uri@services.bunyip.com); Mon, 8 Jan 96 02:24:04 -0500
Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <15289(9)>; Sun, 7 Jan 1996 23:24:00 PST
Received: by golden.parc.xerox.com id <2733>; Sun, 7 Jan 1996 23:23:51 -0800
To: uri@bunyip.com
Subject: Proposed revision of 1738 and possibly 1808
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Larry Masinter <masinter@parc.xerox.com>
Fake-Sender: masinter@parc.xerox.com
Message-Id: <96Jan7.232351pst.2733@golden.parc.xerox.com>
Date: Sun, 7 Jan 1996 23:23:44 PST
X-Orig-Sender: owner-uri@bunyip.com
Precedence: bulk

I'm told that mail to uri@bunyip.com from the end of december might
have been lost, so I'm re-sending from my mail archives.
================================================================
Date: Sun, 26 Nov 95 09:35:28 EST
To: Harald.T.Alvestrand@uninett.no
CC: uri@bunyip.com, klensin@mail1.reston.mci.net
In-reply-to: Harald.T.Alvestrand@uninett.no's message of Fri, 24 Nov 1995 02:41:16 -0800 <9511241041.AA20837@mocha.bunyip.com>
Subject: Re: Vetting rules for UR* schemes
From: Larry Masinter <masinter@parc.xerox.com>

Harald wrote:

> In a fit of frustration over the lack of evaluation criteria for UR*
> schemes, I wrote some.

> See http://domen.uninett.no/~hta/ietf/apps/url-schemes.html

> Comments, changes, flames?


> I'm not planning an RFC on this; I think that my "things to think about"
> documents are better placed on the Net, where I can change them every time
> I change my mind. "Current practice", if not always "best"....

It is my belief that we need to revise 1738 and possibly 1808 if only
to reconcile the differences between them. Along the way, it is
important for the revision of 1738 to say something about 'evaluation
criteria for new URL schemes' if only to set a baseline.

I don't have any complaints about the criteria you've placed, although
I think I might want to restructure the wording about the role of
URLs, e.g., that URLs are used for 'follow this link' in general, but
that in some specific cases, they're used for 'GET me the object
connected to this' or 'POST this object to this location' or 'PUT this
object as a new instance of this location'.

Some kinds of URLs are not appropriate for GET, POST, or PUT, even
though they're appropriate for 'follow this link' (e.g., telnet URLs).
The criterion about being able to proxy should only apply for the
specific object-related URLs rather than the interactive ones, right?

Some possible other considerations:

** clarity in the encoding rules (lots of URL descriptions had trouble
with the wording of how octets and characters got encoded in the URL
characters).

** interactions with 1808 relative URL design (e.g., many gopher URLs
lose because even for hierarchical servers, the 'type' character
appeared at the beginning).

** extensibility, should other parameters become apparently necessary 
================================================================