
Anne van Kesteren wrote:
I'd rather not have vnd.opera.opentype or x-opentype as we'd have to support that forever once shipped which seems like a bad thing. Features introduced on the Web that are successful (and I expect this will be) are not easily removed later on.
If a standard for what you want by a "recognized standards body" (as RFC 4288 puts it), exists, you could directly prepare a registration template, see the RFC 4288 chapter mentioned by Martin. "Standards tree" is not necessarily an IETF RFC, it can be ISO / W3C / ECMA / ... If you have no standard yet and need a new IETF RFC from scratch you are not talking about 2008 or 2009. Or you are not talking about "standards tree". I think it does not need to be application/vnd.opera.opentype if that's not neutral enough. I think the supporters could form some "open font initiative" and pick "ofi", or similar. Some weeks ago I tackled "opensearchdescription+xml" in a draft. That's a bad example, because it must be in the "standards tree", too many of these descriptions exist. But most opensearch ingredients are clear, they just have to be put in a draft, either waiting for a link-relation registry cleanup (adding HTTP), or based on the existing atom-only registry (then the IANA registry still needs a cleanup, but nothing impossible). The hardest part could be to create a schema - if that is necessary, but I think it would be a Good Thing. The OpenSearch draft is short, most of it "TBD", maybe it helps you to get fresh ideas for the *procedural* part of your plan (the IANA considerations registration template). Frank