Re: [apps-discuss] font/* (and draft-freed-media-type-regs)

I see no use case for why having font/opentype is any better than application/opentype

The only use case I can imagine from looking at
http://tools.ietf.org/html/draft-singer-font-mime-00
is the possibility of defining common parameters across font data types (in the same way that text/.. has a common charset parameter).

But there isn't really any common processing proposed that one could do knowing that you have font/x... so I agree with Graham that there isn't a case for font/.

The arguments in favor seem to be of the form "well, we allow for new top level types, so why not use it?"

I also recall a number of years ago an attempt to define "chemical/*" as a new top level type for use in defining file formats?

My conclusion from this discussion is that we should declare the MIME hierarchy closed to new top level types; we've only gotten very limited use and value out of the hierarchy, compared to the pain and difficulty (text/xml vs application/xml).

To be specific: in http://tools.ietf.org/html/draft-freed-media-type-regs
 I would propose changing 

OLD:
   In some cases a new media type may not "fit" under any currently
   defined top-level content type.  Such cases are expected to be quite
   rare.  However, if such a case does arise a new top-level type can be
   defined to accommodate it.  Such a definition MUST be done via
   standards-track RFC; no other mechanism can be used to define
   additional top-level content types.

NEW:

   Originally, it was believed that there might be rare cases where new media types might not "fit" under the currently defined top level types. However, the benefit of introducing a new top level type is likely to be low compared to the additional cost and confusion.  While a new top-level type can be defined by a standards-track RFC, it is likely that additional applications can be satisfied by using the "application/" top-level type.

(Additional comments on draft-freed-media-type-regs in http://www.ietf.org/mail-archive/web/happiana/current/msg00187.html )

-----Original Message-----
From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of t.petch
Sent: Saturday, November 12, 2011 3:28 AM
To: Martin J. Dürst
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*

----- Original Message -----
From: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
To: "t.petch" <ietfc@btconnect.com>
Cc: <dcrocker@bbiw.net>; <apps-discuss@ietf.org>
Sent: Thursday, November 10, 2011 11:47 AM

> On 2011/11/10 18:06, t.petch wrote:
> > Dave
> >
> > My bibles say
> >
> > Type(face) Family; Courier, Futura, Century Schoolbook,  ..
> > Typeface; one of the above with a defined
> >   - Style: Roman, Italic
> >   - Weight: Light, Semibold, Bold, ...
> >   - Width: Ultracondensed, Condensed, Expanded, ...
> > Type Font; one of the above with a defined Size
> >   - eg 12-point
>
> As I said before in a mail to Dave, the last point worked well for 
> lead type or bitmap fonts, but technology has moved beyond.

Martin

The concepts have not changed and remain useful, IMO, in any discussion on presentation.  What has changed is the implementation detail so when I download a new package to my PC, then it will apply to all Fonts, within a Typeface, as opposed to having a separate module for each Font.
(Incidentally, my bibles all relate to laser printing ie to modern technology and have nothing to do with lead:-).

But more significantly, as other posts have clarified for me, this thread is nothing to do with fonts but with type definition languages, so perhaps it should be 'type/*'.

Tom Petch

> Regards,    Martin.

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss