Proposed revision of 1738 and possibly 1808

Larry Masinter (
Sun, 7 Jan 1996 23:23:44 PST

Subject: Proposed revision of 1738 and possibly 1808
From: Larry Masinter <>
Message-Id: <>
Date: Sun, 7 Jan 1996 23:23:44 PST

I'm told that mail to 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
In-reply-to:'s message of Fri, 24 Nov 1995 02:41:16 -0800 <>
Subject: Re: Vetting rules for UR* schemes
From: Larry Masinter <>

Harald wrote:

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

> See

> 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

** 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