Subject: [Sip] SIP-body-handling Open Issue 3

From: Eric Burger <[email-masked]>
Date: Sun, 17 Jun 2007 20:33:11 +0900

I do not think one can say what the Content-Disposition of a multipart/*
body part should be.  From RFC 2183:

   If a Content-Disposition header is used on a multipart body part, it
   applies to the multipart as a whole, not the individual subparts.
   The disposition types of the subparts do not need to be consulted
   until the multipart itself is presented. When the multipart is
   displayed, then the dispositions of the subparts should be respected.

We already have a compatible-with-MIME solution.  Mark the
Content-Disposition of the multipart/* as render, session, or inline with
the needed handling parameter, and have the Content-Disposition of the
sub-parts be whatever they really need to be (if not render).  The logic is
simply to say what you mean.  It really is just a suggestion.  If we are
talking about a multipart/alternative describing sessions, then the
Content-Disposition should be session.  Of course, you could have
Content-Disposition be foobar (or, better yet, inline), so long as (1) the
UAS does not barf and (2) the real Content-Dispositions are present on all
of the sub-parts.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Jun 2007 11:46:55 -0400

>    displayed, then the dispositions of the subparts should be respected.

I've been looking for somebody who understands how this was intended to 
work in MIME. I guess you are that somebody.

The quote above starts with an "if". That makes sense for 
multipart/alternative. But what about a multipart/mixed where the 
individual subparts have different dispositions? We need some content 
disposition that results in the subparts being investigated in an 
appropriate way. But what would that be for sip?

> simply to say what you mean. 

Consider the SDP+ISUP case. The sdp disposition is "session" and the 
ISUP disposition is "signal". What should the disposition of the 
multipart be?

In the case of mail it seems that "render" works, because the multipart 
itself can be rendered. But that doesn't make sense for sip.

> It really is just a suggestion.  If we are

I don't fully know what "inline" means. If we interpreted it to mean 
"inline with the sip processing" then it would be reasonable.

As best I understand it, any part that does not have its own 
content-disposition header has a default that is determined in a 
context-free way, (the default disposition for content-type 
application/sdp is "session" and the for application/isup is "signal") 
and the default-default is "render". I haven't seen any indication that 
the content-disposition is ever inherited from the enclosing body.

So, unless I've missed something, the default disposition for 
multipart/* is "render". But unless we define what it means to "render" 
a multipart in sip then I think this is nonsense.

It may be that for reasons of backward compatibility we should define 
"render" for sip, at least for multipart. But that would be a bit ugly.

	Paul