Hi, Erick says that once we are able to indicate which mime contains the info package, we would be able to allow multiple info packages.
For, that would of course require that we either allow multiple Info-Package headers, or that a single header can list multiple info packages. Regards, Christer > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: 31. lokakuuta 2008 2:36 > To: Christer Holmberg > Cc: Eric Burger; IETF SIP List > Subject: Re: [Sip] 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
