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 ================================================================
- Proposed revision of 1738 and possibly 1808 Larry Masinter