All the standard says is the content-disposition is inherited from the outer multipart. If you want a different disposition for a subpart, you mark it appropriately. In your examples, you would mark the SDP session and the ISUP signal. You could get away with marking the multipart as session, be silent on the SDP, and mark the ISUP as signal. I would offer we recommend UAC's mark all body parts.
-- Sent from my wireless e-mail device. Sorry if terse. We all need lemonade: see <http://www.standardstrack.com/ietf/lemonade> for what lemonade is. -----Original Message----- From: Paul Kyzivat <[EMAIL PROTECTED]> To: Eric Burger CC: Gonzalo Camarillo <[EMAIL PROTECTED]>; [email protected] <[email protected]> Sent: Mon Jun 18 08:46:55 2007 Subject: Re: [Sip] SIP-body-handling Open Issue 3 Eric Burger wrote: > 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. 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? > 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. 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 > 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. 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 > 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 PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > 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 PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
