Subject: [apps-discuss] A modest proposal for MIME types (and URI schemes)

From: Larry Masinter <[email-masked]>
Date: Sun, 13 Nov 2011 10:59:21 -0800

I'd like to discuss the proposal for MIME registrations from Roy Fielding in http://www.ietf.org/mail-archive/web/happiana/current/msg00187.html
and the possibility that such changes should also apply to URI schemes.

You can read Roy's rationale, which makes sense to me, but my summary is: 

* Eliminate standards, vendor, personal trees distinction for MIME types (For URI schemes, eliminate distinction between provisional and permanent schemes)
* ENCOURAGE vendors to ship with vendor-neutral short-named types regardless of whether they have been registered yet or not;
   ENCOURAGE the public to register any names that they have seen in deployed software. (same for URI schemes)
* DO NOT try to avoid duplicates 
* EXPERT REVIEW for updates to existing registrations
* Eliminate any IESG or consensus review requirement

"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."
"There is absolutely no need to prevent people who are not the owners of a media type from registering that type without any prefixes."
"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."

I find this perspective appealing, and can't find anything wrong with it except that it's a break with tradition. If you're at IETF this week and want to talk about it, find me.

Larry

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 13 Nov 2011 22:21:15 +0100

On 13 November 2011 19:59, Larry Masinter wrote:

> I find this perspective appealing

In an ideal world it's not only appealing.  But in
the real world the "secret mission" of the IETF is
IMHO to protect the IANA from "patent nonsense".

It cannot work if *everybody* is free to register
new media types or URI schemes falling into various
WP:NOT categories (= "what Wikipedia is not").

And the IANA also is also not Wikipedia, it is no
dictionary of locations, encyclopedia of emoticons,
registry of vanity URI schemes, or anything else
requiring unlimited disk space or server bandwidth.

-Frank

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 14 Nov 2011 16:09:18 +0900

Hello Larry,

On 2011/11/14 3:59, Larry Masinter wrote:
> You can read Roy's rationale, which makes sense to me,

Some of it makes quite a bit of sense to me, but the first thing that 
doesn't make sense to me is the title of your mail. The proposal seems 
rather radical, not modest.

> but my summary is:

I think that makes sense for something widely known and used (e.g. 
application/pdf), but not necessarily for some really company-specific 
type. (Of course, we don't know in advance which way something may go in 
the end, but we could use this rule at least for when the company e.g. 
wants to express that a type is NOT intended for general use).

>     ENCOURAGE the public to register any names that they have seen in deployed software. (same for URI schemes)

I think third-party registration is indeed something we should encourage 
more.

> * DO NOT try to avoid duplicates

I'm not sure this makes sense. I think it would make sense if it read 
"give up on trying to avoid duplicates at all cost". But it almost reads 
like "let's have many duplicates, this will be fun".

> "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."

Well, but isn't one goal of the effort to get the registry to (more 
closely) reflect reality? In this case, if there are two 
application/foo, and applications recognize one and not the other, then 
there's a disconnect.

Regards,   Martin.

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Graham Klyne <[email-masked]>
Date: Mon, 14 Nov 2011 07:58:34 +0000

On 13/11/2011 18:59, Larry Masinter wrote:
 > I find this perspective appealing, and can't find anything wrong with it 
except that it's a break with tradition.

+1

In particular, I think, the tradition that IANA registries were/are an extension 
point for the IETF standards series (a perspective, if not strictly true).  The 
concern, and this was voiced quite strongly by some participants when we were 
working on the header field registry, is that appearance in an IANA registry may 
give the appearance of being an IETF standard.

But I sense that, in the applications area at least, the world has moved on and 
there are other ways for developers to figure out which options are likely to be 
interoperable.

I think it's worth considering.

#g
--

---

From: Nathaniel Borenstein <[email-masked]>
Date: Mon, 14 Nov 2011 10:32:12 -0500

I certainly don't believe that name collisions are irrelevant; they can cause plenty of problems.  In particular, I don't understand what's supposed to happen in this kind of case:

1.  Company X designs a new media type, perhaps even only for internal use, and registers it as application/foobar

2.  Company Y designs something entirely different and registers it as application/foobar as well.

3.  Each company builds up months or years of experience with their own type, which gets scattered all through the archives, etc.

4.  Company X buys company Y and starts to integrate its infrastructure.

This wouldn't trouble me so much if there were *any* way to tell the two uses apart.  Isn't that the whole point of a registry?  If name collisions are to be allowed, why do we need a registry at all?  Why not just have independent communities of folk wisdom with their own interpretations of media type names, and pay big bucks to consultants to sort out the problems? 

If I want to define a media type for a moving picture flip-book, is it really OK if I call it "My Pictures Emerge Galloping" and use a media type of video/mpeg?  Mightn't my doing that cause problems for a whole lot of people with no responsibility for my idiocy?  -- Nathaniel

---

From: Nico Williams <[email-masked]>
Date: Mon, 14 Nov 2011 12:56:29 -0600

> IMHO to protect the IANA from "patent nonsense".

I assume you're not referring to patents here (as in IPR).

> requiring unlimited disk space or server bandwidth.

I think IANA can jufge frivolous requests.  If not we can require
enough review to filter out frivolous requests.

Aside from this, what is the objection to Roy's proposal?  The more I
think about it, the more I think it's on the money.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 14 Nov 2011 13:06:08 -0600

On Mon, Nov 14, 2011 at 1:09 AM, "Martin J. Dürst"
<[email-masked]> wrote:
>> * Eliminate standards, vendor, personal trees distinction for MIME types
>> (For URI schemes, eliminate distinction between provisional and permanent
>> schemes)
>> * ENCOURAGE vendors to ship with vendor-neutral short-named types
>> regardless of whether they have been registered yet or not;
>
> application/pdf), but not necessarily for some really company-specific type.
> (Of course, we don't know in advance which way something may go in the end,
> but we could use this rule at least for when the company e.g. wants to
> express that a type is NOT intended for general use).

I'm not sure what "really company-specific type" means.  Not to be
leaked on the public Internet?  Even so, and even assuming there's an
enormous number of private-use-only media types (I doubt it), what's
the reason to not encourage registration of them?

> I'm not sure this makes sense. I think it would make sense if it read "give
> up on trying to avoid duplicates at all cost". But it almost reads like
> "let's have many duplicates, this will be fun".

I think we should discourage collisions, but the very existence of the
registry does that.  If a collision arose from registry avoidance, and
implementations have been deployed widely, then what more can we do
but accept it?

>> "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."

If two implementations interpret the same media type name to mean
different things and thus fail to interop, *that* is a collision.
Collisions are bad, but I don't think it's necessary to avoid them at
all costs, since collisions are hardly fatal (the market will pick a
winner, or implementors will disambiguate in some other manner, such
as by content sniffing).

> Well, but isn't one goal of the effort to get the registry to (more closely)
> reflect reality? In this case, if there are two application/foo, and
> applications recognize one and not the other, then there's a disconnect.

If the collision has been deployed, not allowing it to be documented
hardly makes the collision go away.

Nico
--

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 14 Nov 2011 20:29:13 +0100

On 14 November 2011 19:56, Nico Williams wrote:

>> in the real world the "secret mission" of the IETF
>> is IMHO to protect the IANA from "patent nonsense".

> I assume you're not referring to patents here (as in IPR).

"Patent nonsense" is one of the reason for a "speedy
deletion" in Wikipedia.  IANA is not a Wikipedia, it
has no "recent change patrol" to revert vandalism or
controversial "bold" registrations.

> I think IANA can jufge frivolous requests.  If not
> we can require enough review to filter out frivolous
> requests.

That they do not not have to judge this (generally),
because there is an appointed expert and an appeal
chain independent of IANA, is a feature of most IANA
registries I'm interested in.

>From my five happIANA tests the one not yet handled
is a about a registry populated by RFCs, where an old
value in an RFC published before the registry existed
did not yet make it into the registry (as "historic").

-Frank

---

From: Ned Freed <[email-masked]>
Date: Mon, 14 Nov 2011 11:33:47 -0800 (PST)

> > (For URI schemes, eliminate distinction between provisional and permanent

OK, so let's see if I have this straight. There are four subprocesses involved:

(1) Personal type registrations. Rarely used.
(2) Vendor type registration. Commonly and successfully used.
(3) Standards tree registration. Used but has issues with timely processing
    of requests that we're supposed to be tryhing to fix.
(4) Third party revisions and comments process. Essentially never used.

And the proposal is to throw out (1)-(3) and depend on (4) happening because
... well, because.. This seems ... unlikely.

> > regardless of whether they have been registered yet or not;

I think encouraging vendor-neutral registrations would be great. The
question is how we'd actually do it.

> >     ENCOURAGE the public to register any names that they have seen in
> > deployed software. (same for URI schemes)

> I think third-party registration is indeed something we should encourage

How do you propose we do that?

> like "let's have many duplicates, this will be fun".

Agreed.

> application/foo, and applications recognize one and not the other, then

Indeed there is, but not as big as the disconnect in thinking there's a magical
cure here that's going to solve all the problems.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Mon, 14 Nov 2011 13:06:16 -0800 (PST)

> the reason to not encourage registration of them?

There actually a fairly large number of company-specific types, which is why we
allow the company name to be included in the type name. But as you say, the
majority of types aren't of this sort, which is why we don't require the
company name be present.

> implementations have been deployed widely, then what more can we do

Agreed, but in practice it doesn't seem like outright collisions have
been much of an issue.

				Ned

---

From: Nico Williams <[email-masked]>
Date: Mon, 14 Nov 2011 16:11:33 -0600

> Agreed, but in practice it doesn't seem like outright collisions have

I think what Roy F. is saying is that the cost of registration has to
come down a lot.  If collisions are a problem at all they must be a
relatively small problem, and you (and Roy F.) claim that collisions
are of little consequence, in which case we can lower the cost of
registration still more.

Nico
--

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 14 Nov 2011 16:46:41 -0600

Larry,

I was happy to see your positive response to this; what we're trying to do with happiana is aligned with the spirit of what Roy is proposing (as was said later in this thread, to reduce the cost of registration), if not the details (because that's where the devil lies, as pointed out by Frank and others).

Folks who haven't been following that list may want to have a quick look through:
  http://www.w3.org/wiki/FriendlyRegistries
  http://www.w3.org/wiki/FriendlyRegistryProcess

Cheers,

--
Mark Nottingham
http://www.mnot.net/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 15 Nov 2011 07:02:04 +0800

>    http://www.w3.org/wiki/FriendlyRegistryProcess

It's a wiki, feel free to edit. :)

Also, the happiana list is public:

https://www.ietf.org/mailman/listinfo/happiana

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ned Freed <[email-masked]>
Date: Mon, 14 Nov 2011 14:50:57 -0800 (PST)

> come down a lot.

And what I'm saying is that the current cost is, Roy's beliefs to the contrary
notwithstanding, quite low - as in answer a half dozen questions on a web form
low. And we've been actively pursuing various tweaks to move the bar even
lower.

Furthermore, the proposed alternative of allowing a sort of free-for-all where
random folks can register and comment on stuff willy-nilly, is actually pretty
much the process we already have for media type comments. Except here's the
funny thing: Despite the current ready availability of the process that's
supposed to cure all our ills, essentially nobody ever uses it.

> If collisions are a problem at all they must be a

This assumes that currently there's significant cost associated with collision
checks. I can't speak to other registries, but I can assure you the amount
of time spent on this in the case of media types is truly negligable.

				Ned

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 15 Nov 2011 10:43:51 +0900

Hello Ned, others,

> How do you propose we do that?

It seems that currently, people don't even know that it is possible. So 
the first step is to make this more known. On another list, you write: 
"We have always allowed registrations by any interested party." That's 
apparently true, but is it done because nowhere in RFC 4288 it says it's 
not possible? Then making it explicit in draft-freed-media-type-regs 
should help.

For example, you could put in a section 4.12, (Non-)Requirements for 
Contact Information, Author, and Change Controller, saying explicitly 
that third-party registrations are welcome.

This could also explain what in such a case contact information, author, 
and change controller should be. I'd assume that contact information 
goes to the submitter, but change controller stays with the company or 
individual that created the format, but you'll know better what's 
current practice. If I did a third-party registration, this would be the 
place where I'd really not know which way to go.

You can also add pointers to that new section, or just mention the fact, 
in other places where somebody might potentially look. As an example, in 
http://tools.ietf.org/html/draft-freed-media-type-regs-01#section-5.5, 
you could say that in addition to providing comments, new registrations 
and change requests by third parties are also possible.

The next step would then be to put text saying "Media Types may also be 
registered by third parties." or so on the relevant pages at IANA (e.g. 
http://www.iana.org/cgi-bin/mediatypes.pl and 
http://www.iana.org/assignments/media-types/index.html).

Regards,   Martin.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 Nov 2011 02:08:38 +0000

Hi Ned,

On 14/11/2011 19:33, Ned Freed wrote:
> And the proposal is to throw out (1)-(3)
If by "throw out (1)-(3)" you mean just have 1 type of registration, 
then yes, I think this is what Roy proposed.

I would personally like to better understand the thinking behind having 
a separate standards tree registration. What would be disadvanteges of 
dropping (3)? What was the original purpose for having a separate 
registration from vendor types?
> and depend on (4) happening because
  [...]

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 Nov 2011 02:13:29 +0000

Hi Martin,

On 15/11/2011 01:43, "Martin J. Dürst" wrote:
> It seems that currently, people don't even know that it is possible. 
> So the first step is to make this more known. On another list, you 
> write: "We have always allowed registrations by any interested party." 
> That's apparently true, but is it done because nowhere in RFC 4288 it 
> says it's not possible? Then making it explicit in 
> draft-freed-media-type-regs should help.
+1. To be honest I didn't know that this procedure was to be expected. 
In all cases I was expecting that some representative of the 
company/organization that defined the media type should be involved in a 
registration, even if somebody else does the work to actually document it.
> that third-party registrations are welcome.
Exactly.
> This could also explain what in such a case contact information, 
> author, and change controller should be. I'd assume that contact 
> information goes to the submitter, but change controller stays with 
> the company or individual that created the format, but you'll know 
> better what's current practice. If I did a third-party registration, 
> this would be the place where I'd really not know which way to go.
>
> You can also add pointers to that new section, or just mention the 
> fact, in other places where somebody might potentially look. As an 
> example, in 
> you could say that in addition to providing comments, new 
> registrations and change requests by third parties are also possible.
>
> The next step would then be to put text saying "Media Types may also 
> be registered by third parties." or so on the relevant pages at IANA 
> (e.g. http://www.iana.org/cgi-bin/mediatypes.pl and 
Best Regards,
Alexey

---

From: Larry Masinter <[email-masked]>
Date: Mon, 14 Nov 2011 18:15:07 -0800

Who should a third-party registrar list as the "change controller" ?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Tuesday, November 15, 2011 10:13 AM
To: "Martin J. Dürst"
Cc: Roy Fielding; Ned Freed; [email-masked]
Subject: Re: [apps-discuss] Encouraging third party registrations

Hi Martin,

On 15/11/2011 01:43, "Martin J. Dürst" wrote:
>>> I think third-party registration is indeed something we should 
>>> encourage more.
>>
+1. To be honest I didn't know that this procedure was to be expected. 
In all cases I was expecting that some representative of the company/organization that defined the media type should be involved in a registration, even if somebody else does the work to actually document it.
Exactly.
Best Regards,
Alexey

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 15 Nov 2011 11:24:39 +0900

> Who should a third-party registrar list as the "change controller" ?

Good question. I already proposed that it be answered in Ned's document. 
See below.

Regards,   Martin.

---

From: Nico Williams <[email-masked]>
Date: Mon, 14 Nov 2011 21:00:07 -0600

> Who should a third-party registrar list as the "change controller" ?

If collisions don't matter then who cares?  Just add more collisions :)

Alternatively, how about:

   A third party should not claim to be the owner.
   The third party could specify an owner, but that should be considered
      informative.
   Anyone could make a claim on a registration that has no owner already.
   Anyone claiming to be the owner of a registration that already has an
      owner would have to submit their claim to <fill in the blank> (IESG?),
      with appeals going to <fill in the blank> (IAB?).

But I think it's better to just not have to have an owner, nor any
change control -- it's easier and cheaper that way, particularly if it
is true that collisions in this namespace are of little consequence.

Nico
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 15 Nov 2011 12:14:02 +0800

On 11/15/11 11:00 AM, Nico Williams wrote:
> On Mon, Nov 14, 2011 at 8:15 PM, Larry Masinter<[email-masked]>  wrote:
>        owner would have to submit their claim to<fill in the blank>  (IESG?),
>        with appeals going to<fill in the blank>  (IAB?).
>

I think I might buy into that. So the change controller and owner is 
IANA, right? Do we expect that IANA would keep track of who has asked it 
to register or modify any given entry?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Nico Williams <[email-masked]>
Date: Mon, 14 Nov 2011 22:26:32 -0600

On Mon, Nov 14, 2011 at 10:14 PM, Peter Saint-Andre <[email-masked]> wrote:
> I think I might buy into that. So the change controller and owner is IANA,
> right? Do we expect that IANA would keep track of who has asked it to
> register or modify any given entry?

Each entry could be immutable, in which case changes would be in the
form of new entries, and entries would include the name (e-mail
address) of the registrant and various details not just pertaining to
the registration but also to its relation to the others that already
exist.  Sort of like version control; changes -> versions, collisions
-> branches.

---

From: Ned Freed <[email-masked]>
Date: Mon, 14 Nov 2011 20:35:48 -0800 (PST)

> not possible? Then making it explicit in draft-freed-media-type-regs

Seems like a good idea to me. I'll see what I can come up with. Unfortunately
we're in draft-blackout so I can't post a revision.

> that third-party registrations are welcome.

OK.

> place where I'd really not know which way to go.

That's nominally how it works, but I'm not strongly wedded to it as an
approach.

> and change requests by third parties are also possible.

OK.

> http://www.iana.org/assignments/media-types/index.html).

Realistically, that's the place where it is likely to do the most good.

				Ned

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 15 Nov 2011 12:40:56 +0800

> we're in draft-blackout so I can't post a revision.

The blackout is now finished. Or at least I've seen I-Ds coming out.

/psa

---

From: Ned Freed <[email-masked]>
Date: Mon, 14 Nov 2011 20:38:44 -0800 (PST)

> then yes, I think this is what Roy proposed.

No, that's not what I meant. The ad-hoc, incomplete, duplicates allowed
approach being proposed bears a strong resemblance to our current comment and
revision process (4) - you know, the one nobody has ever seen any value in
using.

> registration from vendor types?

The original reason was that people weren't registering their types under the
standards-tree-only rules we originally set up. When we looked at the problem
we didn't see a need for there to be publicly available documentation and
change control associated with a standards body for a format to be useful.  So
we created a means by which formats used by commercial products could be
registered with comparative simplicity and ease.

And the result was people started registering stuff. Of course it wasn't as
many as we hoped, and by this point a large number of unregistered types had
gotten deployed as a result of our original choice to set the bar too high.
We're still paying for that.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Mon, 14 Nov 2011 20:50:09 -0800 (PST)

> IANA, right?

No, if you're going to weaken or even eliminate the owner/change controller
concept - and I think this is an idea that's worth exploring - you need to do
that, not put IANA in the middle of the process as some sort of substitute.

> Do we expect that IANA would keep track of who has asked it

That's how it works currently. In practice I don't believe there has ever been
a problem caused by someone registering something they shouldn't have, and
there definitely have been third party registrations.

				Ned

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 15 Nov 2011 14:23:08 +0900

On 2011/11/15 13:40, Peter Saint-Andre wrote:
> The blackout is now finished.

That's correct. It may be a secret about as well known as the fact that 
third-party media type registrations are allowed, but the blackout 
usually ends when the IETF starts. I'm not sure about the exact time, 
but it's some time Sunday or Monday, and we already have Tuesday.

This is very handy for uploading new drafts for WGs that e.g. met on 
Monday, or otherwise for people who manage to do some draft work during 
the IETF week.

Regards,    Martin.

---

From: Graham Klyne <[email-masked]>
Date: Tue, 15 Nov 2011 08:03:25 +0000

> of time spent on this in the case of media types is truly negligable.

Similarly for header fields and URI schemes.

In practice, I think submitters check this in their own interest.  Completeness 
of the registry could help here.

On this point, I think it's sensible to discourage collision, but not to insist 
on uniqueness in every case.

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Tue, 15 Nov 2011 08:24:37 +0000

> Who should a third-party registrar list as the "change controller" ?

I think the attribute "change controller" belongs to a notion of registries as 
extension-of-standards.  If we move towards registries-as-documentation then I 
think this becomes less important; maybe record "original specifier" instead. 
Or nothing at all, since this information should be available in the linked 
specification document (if there is one).

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Tue, 15 Nov 2011 08:20:22 +0000

On 15/11/2011 01:43, "Martin J. Dürst" wrote:
> It seems that currently, people don't even know that it is possible. So the
> first step is to make this more known. On another list, you write: "We have
> always allowed registrations by any interested party." That's apparently true,
> but is it done because nowhere in RFC 4288 it says it's not possible? Then
> making it explicit in draft-freed-media-type-regs should help.

+1

I think a wiki-FAQ linked from each registry page could go a long way to help.

[[
Make registration procedures / contacts / requirements / guidelines available in 
a user-friendly format (NOT just an RFC) linked from the registry page. E.g., 
give each registry some wiki space linked from its registry page.
]]
-- http://www.w3.org/wiki/FriendlyRegistries#Clear_Process

If we want a simple enhancement to smooth the path of registration, I think this 
is something we could do now which could have a significant effect, without 
updating any RFCs, etc.  As reviewer for URIs and Header fields, I'd be happy to 
put up some initial content for those.  Maybe a common list of FAQs to get this 
started; e.g.

q. Who can register a <foo>?

q. What are the requirements for registering a <foo>?

q. Where should I send my request to register <foo>?

q. What happens next?

q. Who should I contact if I'm not happy with a response to my request?

q. Who has the final say about any registration request?

q. What do I do if I think there is an error in a registration?

q. How do I update a registration?

q. [How] can I add a comment to a registration?

(I've added this suggestion to 
http://www.w3.org/wiki/FriendlyRegistries#Clear_Process)

#g

---

From: "t.petch" <[email-masked]>
Date: Tue, 15 Nov 2011 10:07:58 +0100

I would suggest reading
http://www.ietf.org/mail-archive/web/ietf/current/msg68153.html
and then changing the subject line.

Tom Petch

----- Original Message -----
From: "Larry Masinter" <[email-masked]>
To: <[email-masked]>
Cc: "Roy Fielding" <[email-masked]>
Sent: Sunday, November 13, 2011 7:59 PM
Subject: [apps-discuss] A modest proposal for MIME types (and URI schemes)

> I'd like to discuss the proposal for MIME registrations from Roy Fielding in
http://www.ietf.org/mail-archive/web/happiana/current/msg00187.html
> * Eliminate standards, vendor, personal trees distinction for MIME types (For
URI schemes, eliminate distinction between provisional and permanent schemes)
> * ENCOURAGE vendors to ship with vendor-neutral short-named types regardless
of whether they have been registered yet or not;
> "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."
> "There is absolutely no need to prevent people who are not the owners of a
media type from registering that type without any prefixes."
> "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."
> I find this perspective appealing, and can't find anything wrong with it
except that it's a break with tradition. If you're at IETF this week and want to
talk about it, find me.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 15 Nov 2011 20:14:29 +0900

Graham - Very good idea!   Regards,   Martin.

On 2011/11/15 17:20, Graham Klyne wrote:

> Make registration procedures / contacts / requirements / guidelines
> available in a user-friendly format (NOT just an RFC) linked from the
> registry page. E.g., give each registry some wiki space linked from its
> registry page.
> ]]
> If we want a simple enhancement to smooth the path of registration, I
> think this is something we could do now which could have a significant
> effect, without updating any RFCs, etc. As reviewer for URIs and Header
> fields, I'd be happy to put up some initial content for those. Maybe a
> common list of FAQs to get this started; e.g.
>

---

From: Ned Freed <[email-masked]>
Date: Tue, 15 Nov 2011 08:33:30 -0800 (PST)

> I think a wiki-FAQ linked from each registry page could go a long way to

Very good idea.

> http://www.w3.org/wiki/FriendlyRegistries#Clear_Process)

Great list.

One of the problems with the material in the RFC is that while the overall
process is fairly complex, the process for any given case is not. But you still
have to get past all the other cases to understand yours.

It would help a lot if these links can be made as context-sensitive as
possible, especially if we end up folding standards tree registrations into
the same form.

				Ned