Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review

[Larry Masinter <[e-mail]>]

BCP 35 specifies the process and guidelines for URI schemes, and draft-ietf-appsawg-uri-scheme-reg updates BCP 35, and is effective as soon as it is published.

As far as a prior ruling of non-applicability  to URNs —  what OTHER guidelines or processes would apply to updates of a previously registered scheme? 
But these are GUIDELINES. There is no formal or IANA-enforced requirements or Expert Reviewer override.  IETF consensus on a URN document that directs IANA to change the “urn:” scheme registration will cause the registration to change. Explaining why you’re not following BCP 35 might be helpful in getting IETF consensus, but there is no specifics on what constitutes an adequate justification. 

If there were specific suggestions or comments on how to make BCP 35 into better “best current practice” for the IANA URI scheme, we should fix it. 

To calibrate, I think lifetime of this edition of BCP 35 will be short. It may well be that a more wholesale set of changes of specification and model of URL schemes are needed.

The use of IANA to enumerate schemes is in question, for "the web”;  I think it doesn’t really mesh well with a world with ‘registerProtocolHandler’, which seems to
assume a more dynamic matching of scheme to handler (no IANA involvement at all).

So I think it’s time to reexamine the broader picture. Are “web” and “non-web” and “URN” URL/URI/URNs different things, or are we going to try to keep them together? The tension between having a single protocol element which is used for multiple purposes is in conflict with the requirements of optimum adaptation for specific categories of applications.

https://tools.ietf.org/html/draft-ruby-url-problem-01


in the meanwhile, let’s get this update out.


Larry
—
http://larry.masinter.net