Scope of application/* media types (was: Protocol changes in draft-allbery-usefor-usepro-00)

Russ Allbery <rra@stanford.edu> Fri, 29 December 2006 22:06 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H0Prx-0001lE-FJ for usefor-archive@lists.ietf.org; Fri, 29 Dec 2006 17:06:29 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H0Prv-0000l4-Vc for usefor-archive@lists.ietf.org; Fri, 29 Dec 2006 17:06:29 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBTM34en076765; Fri, 29 Dec 2006 15:03:04 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id kBTM34Nr076764; Fri, 29 Dec 2006 15:03:04 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f
Received: from smtp1.stanford.edu (smtp1.Stanford.EDU [171.67.22.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kBTM33P2076758 for <ietf-usefor@imc.org>; Fri, 29 Dec 2006 15:03:03 -0700 (MST) (envelope-from rra@stanford.edu)
Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DA1B94CC0A for <ietf-usefor@imc.org>; Fri, 29 Dec 2006 14:03:02 -0800 (PST)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id B5E884C936 for <ietf-usefor@imc.org>; Fri, 29 Dec 2006 14:03:02 -0800 (PST)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id AEEA1E7C46; Fri, 29 Dec 2006 14:03:02 -0800 (PST)
From: Russ Allbery <rra@stanford.edu>
To: ietf-usefor@imc.org
Subject: Scope of application/* media types (was: Protocol changes in draft-allbery-usefor-usepro-00)
In-Reply-To: <JAHJs5.FHC@clerew.man.ac.uk> (Charles Lindsey's message of "Mon, 18 Dec 2006 20:04:53 GMT")
Organization: The Eyrie
References: <JA8C4p.Anu@clerew.man.ac.uk> <873b7i9b2m.fsf@windlord.stanford.edu> <JAHJs5.FHC@clerew.man.ac.uk>
Date: Fri, 29 Dec 2006 14:03:02 -0800
Message-ID: <877iwagy21.fsf_-_@windlord.stanford.edu>
User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-usefor@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-usefor/mail-archive/>
List-Unsubscribe: <mailto:ietf-usefor-request@imc.org?body=unsubscribe>
List-ID: <ietf-usefor.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955

Charles Lindsey <chl@clerew.man.ac.uk> writes:
> Russ Allbery <rra@stanford.edu> writes:
>> Charles Lindsey <chl@clerew.man.ac.uk> writes:

>>> 26. [-1] (4.2,4.3) Removed requirement that
>>> application/news-[groupinfo,checkgroups] MUST NOT be used except with
>>> relevant control messages.

>>> Application types are inherently dangerous ...

>> Intentional change.

>> I can't think of an example of how application/news-groupinfo could be
>> dangerous.  It's nothing but a bit of text giving a newsgroup name and a
>> description.  In and of itself, it has no force, power, or action
>> whatsoever.

> Application types are intended to cause applications to be invoked, with
> possible side effects.

Could you provide a reference for this?  I don't see this statement in RFC
2046.  The closest that it has is:

   The "application" media type is to be used for discrete data which do
   not fit in any of the other categories, and particularly for data to
   be processed by some type of application program.  This is
   information which must be processed by an application before it is
   viewable or usable by a user.

"To be processed" is far from saying that reception of an application type
will cause an application to be invoked.  application/octet-stream is an
obvious counter-example to this interpretation.

Our case falls into the general scope ("discrete data which do not fit in
any of the other categories") but not fully into the specific one ("data
to be processed by some type of application program").  Our media types
are actually text/* types; the only reason why they're not declared as
such is because text/* comes with baggage involving CTEs that we can't
accept.  Declaring them as application/* is in essence a hack around the
MIME object structure, although unfortunately a necessary one.

> In this case, the side efect is that a line gets added/changed in the
> Newsgroups file.

I don't agree with this interpretation, and I don't see anything in the
text of the application/news-groupinfo registration that reflects this.
It sounds to me like you're confusing the newgroup control message with
the application/news-groupinfo MIME media type.  They're not the same
thing.

> OK, in that case what you need to say is:

>     This media type is intended to be used in conjunction with the
>     newgroup control message as described in section 5.2.1. It MUST NOT be
>     automatically invoked in any other context without explicit human
>     intervention.

> and similarly for checkgroups.

I disagree with adding anything like this to our document.  When we just
defined the media type to contain simple text and nothing in the
description of the media type says anything about treating that text as
instructions to a computer program, this seems to me to just be confusing.
There's nothing here to invoke; it's just an association between newsgroup
names and descriptions.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>