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

[Eric Burger <[e-mail]>]

Shockingly, +1

On Nov 12, 2011, at 3:25 PM, Larry Masinter wrote:

> 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: [e-mail] [mailto:[e-mail]] On Behalf Of t.petch
> Sent: Saturday, November 12, 2011 3:28 AM
> To: Martin J. Dürst
> Cc: [e-mail]
> Subject: Re: [apps-discuss] font/*
> 
> ----- Original Message -----
> From: "Martin J. Dürst" <[e-mail]>
> To: "t.petch" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss