Re: INFO Framework - one pakage per INFO

I suffered enough in the meeting room.  Up to you to convince the rest  
of the group.

On Nov 28, 2008, at 8:48 AM, Christer Holmberg wrote:

>
> Hi,
>
> If there is no technical reason I don't see why we again shall make a
> restriction which we later may "suffer" from.
>
> Regards,
>
> Christer
>
> -----Original Message-----
> From: Eric Burger [mailto:[email protected]]
> Sent: Friday, November 28, 2008 3:39 PM
> To: Christer Holmberg
> Cc: SIP List
> Subject: Re: [Sip] INFO Framework - one pakage per INFO
>
> It was a consensus thing, not a technical thing :-)
>
> On Nov 20, 2008, at 8:19 AM, Christer Holmberg wrote:
>
>>
>> Hi,
>>
>> I probably missed it, but what is the justficiation for only one Info
>> Package body per INFO request?
>>
>> Didn't we discuss it earlier, and came to the conclusion that it
>> wouldn't add any extra complexity?
>>
>> ...especially, as you say, one MUST support multipart anyway.
>>
>> Regards,
>>
>> Christer
>>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf Of
>> Eric Burger
>> Sent: Thursday, November 20, 2008 2:44 AM
>> To: SIP List
>> Subject: [Sip] INFO Framework
>>
>> Consensus stuff:
>>
>> 1. Remove Send-Info. It takes away a bunch of race conditions. The
>> value of having it is theoretical. We can always add it in later, so
>> we will keep the header name "Recv-Info".
>>
>> 2. Remove Contact: header from INFO table
>>
>> 3. Remove Recv-Info from INFO table
>>
>> 4. Mention what happens when you forget the Recv-Info header when you
>> refresh a dialog
>>
>> 5. Only one Info Package body in the INFO method request. However,
>> implementations MUST support multipart, per RFC 3261 as updated by
>> body-handling.
>>
>> If you disagree with these items, squeak now.  Send us an INFO.
>

_______________________________________________
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