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

From: "Eric Burger" <[email-masked]>
Date: Mon, 18 Jun 2007 09:45:33 -0700

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-masked]>
To: Eric Burger
CC: Gonzalo Camarillo <[email-masked]>; [email-masked] <[email-masked]>
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-masked] for questions on current sip
> Use [email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip