- From: Larry Masinter <LMM@acm.org>
- Date: Sun, 29 Aug 2004 16:48:49 -0700
- To: uri@w3.org
- Cc: djz@corp.webtv.net, rpetke@wcom.net, "'Harald Tveit Alvestrand'" <harald@alvestrand.no>, Tony Hansen <tony@att.com>, "'Paul Hoffman / IMC'" <phoffman@imc.org>
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