Re: Proposal for multiple INFO bodies in an INFO

Of course I agree with all the stuff below on the necessity of dealing 
with multipart bodies.

While I was advocating a Content-Disposition mechanism for identifying 
the relevant part(s), I have no problem with the CID: mechanism. If we 
go that way I think we should *always* use the CID reference.

	Thanks,
	Paul

Eric Burger wrote:
> 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