Re: Vetting rules for UR* schemes

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 Sunday, 26 November 1995 12:36:32 UTC