IPP Mail Archive: IPP> cc: re: Content-disposition: A better place for command verbs?

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

Ralph Patterson (rpatters@lan-aces.com)
Thu, 9 Oct 1997 08:36:00 -0500

On Thursday, October 09, 1997 7:06 AM, Harald.T.Alvestrand@uninett.no
wrote:
>
>Date: 9-Oct-97 7:06:10 -0500
>From: Harald.T.Alvestrand@uninett.no
>To: find@bunyip.com,
>Subject: Content-disposition: A better place for command verbs?
>
>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

**** Comment from Ralph Patterson on 10/09/97 at 8:14 AM CST ****
Harald,
If I understand what you are suggesting correctly, this was addressed
early on in the iCalendar discussion. I believe the consensus was that
putting disposition information *only* in the MIME header caused the
iCalendar object to fail at being a self contained "object". Again, if I
recall correctly, the concern was that even though the specification is
for MIME encapsulated information, the iCalendar object itself may not
stay MIME encoded for the duration of the process (e.g., gateways to
other messaging systems, certain e-mail packages (e.g., Eudora) that
split the attachment from the message, etc.).

Now, if that is not what you were suggesting, I'm sorry for the
interruption and everyone can resume their normally scheduled broadcast
day.

Ralph Patterson