Subject: IPP> Content-disposition: A better place for command verbs?

From: [email-masked]
Date: Thu, 09 Oct 1997 14:06:10 +0200

Hi,
as some of you know, I've been somewhat worried about the recent trend
to try to define MIME types that have more or less the same content
(or even no content), but different names, because they indicate
different things that the sender wants the recipient to do.

Recently, an I-D crossed my desk: draft-rfced-exp-whalen-00.txt
Now the actual draft is quite dangerous, because it confuses
"program name" with "desired function", effectively making it just too
easy to create an "execute anything" facility without intending to.
But the basic idea might have a point:

*> Architecturally, I think the "command verb" part fits better as a <*
*> content-disposition modifier than as a MIME type.                 <*

So - it SHOULD be possible to define a content-disposition modifier
that is adequately narrow, for instance:

Content-type: application/job-id
Content-disposition: process; proto=ipp; request=return-status

Content-type: appication/event
Content-disposition: process; proto=imip; request=counteroffer

Content-type: index/cip-tokenized-index-delta
Content-disposition: process; proto=cip; request=merge

I know that several of you are quite far along the track already, and may
not want to rethink the usage you make of MIME types, but I think it's worth
spending at least 3 minutes thinking about where you put the "command verb".

Have fun!

                    Harald A

---

From: Keith Moore <[email-masked]>
Date: Thu, 09 Oct 1997 15:13:44 -0400

> spending at least 3 minutes thinking about where you put the "command verb".

Let's see...how many possible ways of dispatching email things do we have:

1. content-type
2. parameters of content-types
3. content-disposition keyword (as proposed here)
4. the portion of the filename after the '.'
5. using different email addresses for different purposes
6. using different subaddresses of a single email address
7. using a directory entry to indicate which email address is used 
   for which purpose
8. SRV records  (just for completeness...please, let's not go there)

Any more?  This seems like plenty...

It would be nice to have some shared idea of which of these should
never be used, and when to use those that remain.

Given that we have so many ways to dispatch things already, I'm
inclined to think that this new proposal is of marginal value.

Keith