- From: Tony Hansen <tony@att.com>
- Date: Mon, 09 Aug 2004 09:12:56 -0400
- CC: uri@w3.org
Graham, your message header registry is exactly the model I intend to follow in the 2717 rewrite Ted and I will be working on. Tony Graham Klyne wrote: > > 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 13:13:29 UTC