URI registration (was: Minutes URIREV04 BOF)

Many of the points raised below were discussed when we were working on 
registries for email headers [1], which have now been approved and are 
awaiting RFC publication.

While I won't claim that the model is perfect for URIs, maybe it's worth 
taking a look at it for ideas?

Ah, now I see the message header field registry was noted in 
discussion.  Anyway, here's a reference for anyone interested [1].

#g
--

[1] http://www.ietf.org/internet-drafts/draft-klyne-msghdr-registry-07.txt


At 20:55 08/08/04 -0700, Larry Masinter wrote:
>* URI registration is broken:
>
>The public perception of URI scheme registration is off from
>reality. There are many schemes whose attempted registration has
>languished for years without any deterministic process for either
>registering them or saying 'no' definitively.
>
>We originally made an exception to the guidelines for URI schemes
>which allowed schemes to be registered even if they didn't quite meet
>the guidelines if they were widely deployed. The result has been
>people just use their scheme and hope that if they get widely
>deployed, they will get a registration.
>
>The original intent of the high bar was keep the number of registered
>schemes down.  But people just mint them, and plan to register later.
>Now are seeing conflicts; e.g., 'mmms:' has diffenent interpretations
>used by 3GPP and Microsoft. We need to fix this.
>
>Ted suggests that we abandon the idea that registration will reduce
>total number. Our only purpose should be to eliminate namespace
>conflicts.
>
>* What's in the registry? Is there a 'line'?
>
>We discussed various forms of registries that might set some line --
>schemes below the line not as good as schemes above the line. A
>provisional registration followed by a permanent one after six months,
>etc.
>
>Ted suggests a provisional registration that provides a specification
>or an implementation pointer, for six months.  If someone already has
>a provisional registration and a spec, they win, they get in.
>
>James suggests that perhaps the rule is that the scheme has to have
>two different implementations.
>
>Leslie asks how one might make a URI processor that can handle a
>zillion different schemes.
>
>Leslie suggests that there are two classes: ones with published specs,
>one without; we should discourage non-protocol schemes.
>
>Requiring a 'definition' or a 'protocol' for a scheme might not be
>enough; Paul gave an example of a scheme with a 'definition' which is
>'just like http', i.e., it's well-defined, but useless as a URI
>scheme.
>
>John points out that if we set up barriers, people will do whatever
>they do anyway.
>
>Larry suggests registering implementations of URI schemes.
>
>Larry says rather than setting a threshold ("must have at least 1
>implementation") just document the values in the registry, and let
>people come to their own conclusions.
>
>Leslie says the criteria might be running code and/or specification is
>enough to get above the line.  Larry wants us to never draw a line.
>Larry wants us just list pointers; people will game the line.
>
>Leslie thinks that "community vote" is OK, as long as we clearly
>define what is IETF (as in: on standards track). Larry agrees.
>
>* Abuse:
>
>Roy says that we might also need to worry about preventing abuse,
>e.g., registering URI schemes with other people's trade names, etc.
>
>John points out that there is an easy denial-of-service on other
>people's names. With IANA and port numbers, the rule was 'you get one
>for free' but for the second registration, you need to provide
>something, e.g., a protocol definition.
>
>Paul says there are big WIPO problems.  John says that WIPO will
>probably just let people sue each other.  John says that ICANN just
>defers to WIPO.
>
>Paul talked about formal association with WIPO.
>John points out (again) about insanity and WIPO.
>
>James says we don't have a problem now because the bar is so high; if
>we lower the bar, it's going to become a problem.
>
>Geoff talks about WGs "preemting" registration. [[ed: ??]]
>
>* Duplicates (and comparison to header registry)
>
>Larry suggested that perhaps allowing multiple registrations for the
>same scheme might be allowed. This caused wild disagreement in the
>room ("that's nuts", "terrible, terrible", "if we allow collision,
>let's just not do this").
>
>Pete says we had the same fight about the header registry; points out
>that we wanted a single place for people who didn't want to have a
>conflict to look.
>
>Pete thinks that we can have duplicates in the registry.  Pete says
>"document usage, allow people to see what isn't use".  John says let
>the bad guys duke it out.
>
>Leslie asks "what happens when a bad guy wants to add a second
>registation for urn:?".
>
>Larry thought that allowing duplicates might reduce some DoS
>values, because someone else registering 'roy:' wouldn't stop
>Roy from using it.
>
>Ted thinks the bar should be set above allowing multiple registration.
>
>Martins says the Web just doesn't work with multiple schemes.  Martin
>wants each one clear, and wants to resolve the problem with the
>current duplicates.
>
>Leslie would have preferred a universe with just one, and a smaller
>number of schemes. But she wants to acknowledge reality. We should
>give the clearest picture possible of the universe.
>
>Ted acknowledges that keeping the number of URI schemes low was not of
>benefit to the user. Argues that trying to shape it to avoid collision
>is paramount.  Paul agrees with Leslie.
>
>John points out that the header registry's purpose is to say "here's
>the legitimate use of foo, but there is another use".  The header
>registry is used for security and user-defense warning (e.g.,
>which systems might send headers which have different meanings).
>
>Martin asks if the header registry works and what implementers think
>of it; how do negative comments get into the registry?
>
>John says the negative comments can get there through the standards
>process.
>
>Tony Hansen clarifies how the header registry works.

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Monday, 9 August 2004 09:35:38 UTC