updating RFC 2718 (Guidelines for new URL schemes)

I spent a little time looking over RFC 2718 and
suggest the following changes in the update
(Tony Hansen & Paul Hoffman volunteered to help
with the update).

I've actually started to draft some updated text
according to the following suggestions, but I thought
I would review the changes and let Tony and Paul
decide what they want.


Section 1 Introduction:

(and throughout, as appropriate):

* Change 'URL scheme' to 'URI scheme' most everywhere.
  Add a brief explanation about the transition.
* Update authors list, as necessary
* Change references to RFC2396bis and RFC2717bis.
* Change 'track' to BCP from Informational


Section 2 Guidelines:

This may need a little reorganization. I think this
was originally taken from Harald's list of "things
to think about" (as might have been appropriate for
an Informational document), but I'd rather see these
expressed as proscriptive guidelines, where possible.

The sections are
  2.1 Syntactic compatibility
  2.2 Is the scheme well defined?
  2.3 Demonstrated utility
  2.4 Are there security considerations?
  2.5 Does it start with UR?
  2.6 Non-considerations

* Syntactic compatibility

I think the sentiments in this section are good; I'm uneasy
about the lengthy 'motivation for syntactic compatibility',
since it's really not just a motivation, but also an explanation
for what is meant by 'syntactic compatibility'. I think
some of the Motivations are confused (e.g., the discussion
about fragment syntax, but URI schemes don't define
fragment syntax!)

So I think this section can be reduced to asking that
URI schemes use RFC2396bis generic syntax, because of
compatibility with relative references.

* 2.2 Is the scheme well defined?

This should be turned into a guideline rather than
a question, with the suggestion that there are
resource locator schemes and non-locator schemes.
I think it's useful if schemes are clear about whether
(or under what circumstance) the 'resource' might be
something that returns a (body/entity/...?) which has
a Media Type, and can be used with fragment identifiers
in their conventional definition.

* 2.2.5 Character encodings

I think this turns into a requirement for compatibility
with IRI guidelines. Maybe there is a place here to
note that there is only one namespace, a "URI scheme"
is also an "IRI scheme".

2.3 Demonstrated utility

I'd like to suggest that we require something stronger: that new
URI schemes have demonstratable, new, long-lived
utility:

  Because URI schemes are a single, global namespace, the
  unrestricted registration of many new URI schemes can
  clutter implementation space, and possibly lead to
  contention for "short names". For this reason, new
  URI schemes should have a clear utility to the broad
  Internet community, and provide some means of identifying
  resources that is not already available with previously
  registered URI schemes.

Perhaps this is controversial :)

2.3.1 Proxy into HTTP/HTML

This seems like it isn't a criteria for demonstrated utility,
but perhaps even the converse. Perhaps a proxy might
tell you about whether a scheme can be interpreted
with GET, PUT or POST, and thus might be more well-defined
than one that can't.

2.4 Are there security considerations?

I think it's mainly the section title that could be
replaced.

2.5 Does it start with UR?

I think the 'intense debates' around other URs have passed;
I don't mind keeping the restriction.

Larry (let the flames begin!)

-- 
http://larry.masinter.net

Received on Sunday, 29 August 2004 23:48:58 UTC