
Hi, Relatively soon Opera and Mozilla will ship with support for downloadable fonts. Rather than sniffing, as currently happens for images, or ignoring MIME types altogether (ECMAScript), we think it would be good to actually check for a MIME type this time around. :-) What would be a good MIME type to check for here? * font/opentype * application/opentype * something else? How do we go about registering this? Also, how do we ensure the registration happens fast enough for us to be able to implement it on time? Historically, if the implementation doesn't do things like this correctly from the start, it's close to impossible to fix it later on (see e.g. images or ECMAScript). (We realize Apple already shipped with this functionality without checking but we have some hope that can still be resolved by authors fixing their resources to also make it work for us and then later Apple fixing their product as well.) Thanks for your consideration and time, -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>

At 18:22 08/08/22, Anne van Kesteren wrote:
Hi,
Relatively soon Opera and Mozilla will ship with support for downloadable fonts. Rather than sniffing, as currently happens for images, or ignoring MIME types altogether (ECMAScript), we think it would be good to actually check for a MIME type this time around. :-)
What would be a good MIME type to check for here?
* font/opentype
This will take ages, if ever.
* application/opentype
Seems a reasonable target.
* something else?
How do we go about registering this?
Read http://www.ietf.org/rfc/rfc4288.txt. In particular 3.1, and then some other stuff.
Also, how do we ensure the registration happens fast enough for us to be able to implement it on time?
What is your time frame? If you want this to be fast, something like application/vnd.opera.opentype (see section 3.2). Otherwise, fast turnaround when submitting internet-drafts, and serious addressing of comments on this list is probably the most important. Also, try to talk to one of the Application Area Directors (Chris Newman or Lisa Dusseault), because you need one of them for sponsoring through the IESG if you want to go the standards route. Regards, Martin.
Historically, if the implementation doesn't do things like this correctly from the start, it's close to impossible to fix it later on (see e.g. images or ECMAScript).
(We realize Apple already shipped with this functionality without checking but we have some hope that can still be resolved by authors fixing their resources to also make it work for us and then later Apple fixing their product as well.)
Thanks for your consideration and time,
-- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp

On Fri, 22 Aug 2008 10:42:19 +0100, Martin Duerst <duerst@it.aoyama.ac.jp> wrote:
At 18:22 08/08/22, Anne van Kesteren wrote:
Also, how do we ensure the registration happens fast enough for us to be able to implement it on time?
What is your time frame?
I understood that for Mozilla its a couple of months (though I can't really speak for them, understandably), for Opera it's sooner.
If you want this to be fast, something like application/vnd.opera.opentype (see section 3.2).
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. (For <script type> we recognize eleven or so MIME types meaning ECMAScript...) -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>

At 18:54 08/08/22, Anne van Kesteren wrote:
On Fri, 22 Aug 2008 10:42:19 +0100, Martin Duerst <duerst@it.aoyama.ac.jp> wrote:
At 18:22 08/08/22, Anne van Kesteren wrote:
Also, how do we ensure the registration happens fast enough for us to be able to implement it on time?
What is your time frame?
I understood that for Mozilla its a couple of months (though I can't really speak for them, understandably), for Opera it's sooner.
May be really tough. I guess it's better to start now. Why don't you fill in a registration template and send that here to move things on?
If you want this to be fast, something like application/vnd.opera.opentype (see section 3.2).
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. (For <script type> we recognize eleven or so MIME types meaning ECMAScript...)
There is a big difference between x-opentype, which is really bad private use, and vnd.xyz.opentype, which is totally okay because it's registered and all. I guess opera as a company was the wrong idea, maybe adobe would work better? If you can get somebody from Adobe to submit this registration, it might be done in a couple days. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp

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

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 / ...
In my understanding, Open Type 1.4 is ISO/IEC 14496-22 and 1.5 is also in progress in SC29. If this is correct, one possibility is: 1) JTC1 publishes registration information (on the basis of the template in RFC 4288) as an amendment of or technical corrigenda to ISO/IEC 14496-22, or incorporate registration info as part of the next standard for 1.5, and 2) SC29 sends a registration request to IESG. Of course, the registration information should meet requirements stated in Section 4 of RFC 4288. Cheers, -- MURATA Makoto <murata@hokkaido.email.ne.jp>
participants (4)
-
Anne van Kesteren
-
Frank Ellermann
-
Martin Duerst
-
MURATA Makoto