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
