On Nov 9, 2011, at 9:37 AM, John C Klensin wrote: > --On Tuesday, November 08, 2011 16:15 +0900 "\"Martin J. > Dürst\"" <duerst at it.aoyama.ac.jp> wrote: > >>> -- Once the expert review process does its thing, the >>> registration is handed off to IANA. IANA announces the >>> registration for a short period of external review and comment >>> (we make a new list, give them access to IETF-Announce for >>> that purpose, and announce in both places). >> >> There's already ietf-types at iana.org. Why would we need a new >> list? And why do you think announcing it to all the IETF is >> necessary? > > Because this is the equivalent to a standards-track action > (which is why the IESG was involved in the first place) and > people who do not follow the ietf-types list might have > perspectives or competent opinions on such a type. Of course, > announcing it to the IETF list increases the odds of incompetent > opinions, but that is sort of the price we pay. > > An alternative, of course, would be to let "recognized SDOs" > register anything they like, or anything they have first > standardized themselves. I could live with that but would be > surprised if the IETF community could, at least without raising > the threshold for "recognized" considerably. > > john The reality that I deal with, as the maintainer of the Apache types file, is that any review whatsoever is far more harmful than inaccurate information in the registry. The inaccurate information can be fixed if we allow people other than the registrant to file corrections. Failing to register (and then insisting that only the owner can register) makes the registry worse than useless. It actively interferes with my work. Likewise, splitting the registry into standards and vendors and personal types was an utter and complete failure that made the situation worse. There is no *need* for them. The only thing that it has accomplished is the further prevalence of x-types for vendor-neutral data formats, and we can never change those type names because there is no way for us to change the deployed client software that expects them. People deploy with x-types because they mistakenly think that is what we want them to do if a type has not yet been registered. They do not register their types before deployment because they are either in stealth mode (no pre-release about the product before it is announced) or because it is perceived to be a waste of time during the last minute struggles to ship a new product. And once the product ships, that x-type is etched in stone because the servers can only send types that all deployed clients will understand. We should be *encouraging* vendors to ship with vendor-neutral short-named types regardless of whether they have been registered yet or not, and then we should be *encouraging* the public to register any names that they have seen in deployed software. There is absolutely no need to prevent people who are not the owners of a media type from registering that type without any prefixes. There is absolutely no need to prevent name collisions in the registry itself because those collisions are irrelevant -- what matters is how the names are interpreted by recipients of messages. So let's stop wasting our time with silly roadblocks that discourage folks from registering a type before using it on the Internet, because we know damn well that none of these software companies (including my $work) will register a type before using it on the Internet. That review serves no purpose. What we do need a review for is changes requested to existing types after they have been registered, just to avoid abuse of popular types, but that can be accomplished by expert review. There is no need for the IESG to be involved in any of this, nor is there need for consensus within the IETF. The registry is not operable -- it is just documentation of how the Internet is operating, and it should reflect the reality of that operation even if that means we have multiple definitions per registered type. ....Roy
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.