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

Eric Burger <eburger@standardstrack.com> Sun, 13 November 2011 18:06 UTC

Return-Path: <eburger@standardstrack.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A8721F8548 for <apps-discuss@ietfa.amsl.com>; Sun, 13 Nov 2011 10:06:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.338
X-Spam-Level:
X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J16V+JCPr5aA for <apps-discuss@ietfa.amsl.com>; Sun, 13 Nov 2011 10:06:58 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id 38B4221F861E for <apps-discuss@ietf.org>; Sun, 13 Nov 2011 10:06:58 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=k7X+T5MwnpGTPAspzUVyR/wkVv/7l1np7jWztph+eT+/D60ZNVQlCmp842rcoVX0GH1zPntnuZJo+6Uj4AYOmvdmuRAW11wC/4+88cf+8yEPh258pAV/36iLKaDqIEQK;
Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:58031 helo=[192.168.15.184]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <eburger@standardstrack.com>) id 1RPeS3-0003ci-Mn for apps-discuss@ietf.org; Sun, 13 Nov 2011 10:06:44 -0800
From: Eric Burger <eburger@standardstrack.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-166--696982848; protocol="application/pkcs7-signature"; micalg=sha1
Date: Sun, 13 Nov 2011 13:06:40 -0500
In-Reply-To: <C68CB012D9182D408CED7B884F441D4D0611DABF0F@nambxv01a.corp.adobe.com>
To: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
References: <C68CB012D9182D408CED7B884F441D4D0611DABF0F@nambxv01a.corp.adobe.com>
Message-Id: <8D5D1E18-FA41-475E-9570-46B9739741E3@standardstrack.com>
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Nov 2011 18:06:59 -0000

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: 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>et>; <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
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss