Re: [apps-discuss] font/*

Graham Klyne <> Sat, 12 November 2011 09:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4E5121F8880 for <>; Sat, 12 Nov 2011 01:31:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FUNCU5oz-mYe for <>; Sat, 12 Nov 2011 01:31:16 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D68E221F85F1 for <>; Sat, 12 Nov 2011 01:31:15 -0800 (PST)
Received: from ([]) by with esmtp (Exim 4.75) (envelope-from <>) id 1RP9vZ-0001xM-2X; Sat, 12 Nov 2011 09:31:09 +0000
Received: from ([] helo=Eskarina.local) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1RP9vZ-0007ri-1T; Sat, 12 Nov 2011 09:31:09 +0000
Message-ID: <>
Date: Sat, 12 Nov 2011 08:14:58 +0000
From: Graham Klyne <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: "\"Martin J. Dürst\"" <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Oxford-Username: zool0635
Cc:, "" <>
Subject: Re: [apps-discuss] font/*
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 12 Nov 2011 09:31:16 -0000

On 10/11/2011 01:47, "Martin J. Dürst" wrote:
> On 2011/11/09 10:16, Dave CROCKER wrote:
>> On 11/8/2011 4:27 PM, Graham Klyne wrote:
>>> It's not clear to me what purpose would be served that cannot be handled
>>> perfectly adequately by application/*
> Then why do we have image/, audio/, and video/? application/ would be perfectly
> adequate for them, wouldn't it?

My supposition (and this is probably no more than post-hoc rationalization) was 
that the top level types were available for routing messages to an appropriate 
client, which might be a different device in a multimodal environment.  E.g. 
text/* to device that handles text, image/* to one that handles static images/*, 
similarly for audio/* and video/*.

Application/* then becomes appropriate for any content that doesn't depend on 
any particular presentation capabilities or modalities.

Interestingly, model/* has been mentioned in discussion as an example.  With 
increasing use of personal 3D printing (cf. and spinout 
projects), I think it's a top-level type who's time is coming.  (I've even 
wondered about an update for RFC 1437...)

Of course, it all hinges on why we have top-level types at all.  From, a purely 
taxonomical perspective, I think a strictly 2-level hierarchy is always going to 
call for some arbitrary choices.