Re: Proposal for multiple INFO bodies in an INFO

Either way can allow multiple. The means for expressing it are somewhat 
different, but not of consequence.

	Thanks,
	Paul

Christer Holmberg wrote:
> 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