Re: [apps-discuss] font/*

Graham Klyne <GK@ninebynine.org> Sat, 12 November 2011 09:31 UTC

Return-Path: <GK@ninebynine.org>
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 C4E5121F8880 for <apps-discuss@ietfa.amsl.com>; Sat, 12 Nov 2011 01:31:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUNCU5oz-mYe for <apps-discuss@ietfa.amsl.com>; Sat, 12 Nov 2011 01:31:16 -0800 (PST)
Received: from relay0.mail.ox.ac.uk (relay0.mail.ox.ac.uk [129.67.1.161]) by ietfa.amsl.com (Postfix) with ESMTP id D68E221F85F1 for <apps-discuss@ietf.org>; Sat, 12 Nov 2011 01:31:15 -0800 (PST)
Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay0.mail.ox.ac.uk with esmtp (Exim 4.75) (envelope-from <GK@ninebynine.org>) id 1RP9vZ-0001xM-2X; Sat, 12 Nov 2011 09:31:09 +0000
Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <GK@ninebynine.org>) id 1RP9vZ-0007ri-1T; Sat, 12 Nov 2011 09:31:09 +0000
Message-ID: <4EBE2B02.8070500@ninebynine.org>
Date: Sat, 12 Nov 2011 08:14:58 +0000
From: Graham Klyne <GK@ninebynine.org>
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: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>
References: <4EB86078.8070904@stpeter.im> <4EB8E7FA.5030406@ninebynine.org> <4EB9D46B.8010808@dcrocker.net> <4EBB2D1B.5010206@it.aoyama.ac.jp>
In-Reply-To: <4EBB2D1B.5010206@it.aoyama.ac.jp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Oxford-Username: zool0635
Cc: dcrocker@bbiw.net, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] font/*
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: 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. http://reprap.org 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.

#g