- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Sun, 7 Jan 1996 23:23:44 PST
- To: uri@bunyip.com
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 ================================================================
Received on Monday, 8 January 1996 02:24:41 UTC