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:eburger at standardstrack.com] 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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] 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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip