Re: Proposal for multiple INFO bodies in an INFO

I am ok with either way.

I think using C-D follows the precedent of INVITE for finding "its body 
part" via C-D of "session".

	Thanks,
	Paul

Christer Holmberg wrote:
> Hi Erick,
>  
> I am not your suggestion of using CID for Info packages is what has been discussed (I may be wrong, of course).
>  
> I think what Paul was proposing was to have a Content-Disposition value indicating that a particular body shall be treated as in info package.
>  
> INFO .....
> To: ....
> From: ....
> Info-Package: foo
> Content-Type: application/foo
> Content-Dispotistion: info
> ...
> 
> <foo body>
> 
> 
> Multipart mixed example with indirect content:
> 
> INFO ....
> To: ....
> From: ....
> Info-Package: foo
> Content-Type: multipart/mixed;boundary="theboundary"
> ...
> 
> --theboundary
> Content-Type: application/mumble
> Content-Disposition: whatever
> 
> <mumble body>
> 
> --theboundary
> Content-Type: application/foo
> Content-Disposition: info
> 
> <foo body>
> 
> --theboundary--
> 
>  
>  
> Regards,
>  
> Christer
> 
> ________________________________
> 
> From: [email protected] on behalf of Eric Burger
> Sent: Thu 30/10/2008 19:29
> To: IETF SIP List
> Subject: [Sip] Proposal for multiple INFO bodies in an INFO
> 
> 
> 
> Good thing I waited 10 days...
> 
> Initially, I was very swayed by the argument that things would be 
> much, much easier if we restricted an INFO request to a single Info-
> Package.
> 
> However, and especially as the last person to touch RFC 4483, I can 
> see the argument that *any* SIP message can end up with a multipart/
> mime body, even if you think you can limit it to just your stuff, 
> because the UA can always have a content indirection pointer in the 
> header pointing to a mime body part.
> 
> Therefore, even if we restrict an INFO request to carry a single Info-
> Package, we need a mechanism to uniquely identify and, at the SIP 
> header level, indicate which body part belongs to the package.
> 
> I would offer once we solve that, we also get multiple INFO request 
> bodies for free.
> 
> I would also offer that since INFO does not change SIP state, which 
> means there is not even a concept of a message succeeding but the INFO 
> body doing something that "fails", the objection that it would be hard 
> for a UA to report on one body "failing" with another body 
> "succeeding" is a non-issue.  Yes, this does mean that you cannot use 
> INFO to tunnel IP.  See RFC 3252 for more on this.  I do not see this 
> as a problem.
> 
> Therefore, on to the solution.  We use the MIME approach.  The body 
> parts get tagged with Content-IDs. The Info-Package has a parameter, 
> CID, which points to the body part.  The ONLY question I have is 
> whether we should simply mandate always having this parameter to make 
> the protocol and parser easier, but a small burden on UAC's that 
> really are only sending a single body.  Other than that, the mechanism 
> looks like:
> 
> INFO .....
> To: ....
> From: ....
> Info-Package: foo
> Content-Type: application/foo;cid=this
> Content-Id: this
> ...
> 
> <foo body>
> 
> 
> 
> Multipart mixed example with indirect content:
> 
> INFO ....
> To: ....
> From: ....
> Info-Package: foo;cid=abcd1234zz
> Mumble: <cid:abcd9999qq>
> Content-Type: multipart/mixed;boundary="theboundary"
> ...
> 
> --theboundary
> Content-Type: application/mumble
> Content-Id: abcd9999qq
> ...
> 
> <mumble stuff>
> 
> --theboundary
> Content-Type: application/foo
> Content-Id: abcd1234zz
> 
> <foo body>
> 
> --theboundary--
> 
> 
> 
> 
> Multiple Info Packages follow. Note that by using Content-Id, order is 
> irrelevant.
> 
> INFO ....
> To: ....
> From: ....
> Info-Package: foo;cid=abcd1234zz
> Info-Package: bar;cid=wxyz9876
> Content-Type: multipart/mixed;boundary="theboundary"
> ...
> 
> --theboundary
> Content-Type: application/bar
> Content-Id: wxyz9876
> ...
> 
> <bar stuff>
> 
> --theboundary
> Content-Type: application/foo
> Content-Id: abcd1234zz
> 
> <foo body>
> 
> --theboundary-- 
> 
> _______________________________________________
> Sip mailing list  https://www.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
> 
_______________________________________________
Sip mailing list  https://www.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