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 valueof 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 From sip-bounces at ietf.org Fri Nov 28 05:39:02 2008
Return-Path: <sip-bounces at ietf.org> X-Original-To: sip-archive at optimus.ietf.org Delivered-To: ietfarch-sip-archive at core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 266933A6A4A; Fri, 28 Nov 2008 05:39:02 -0800 (PST) X-Original-To: sip at core3.amsl.com Delivered-To: sip at core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2A728C0F3 for <sip at core3.amsl.com>; Fri, 28 Nov 2008 05:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mt7A+dV3-o9l for <sip at core3.amsl.com>; Fri, 28 Nov 2008 05:39:00 -0800 (PST) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 18E5C3A69EE for <SIP at ietf.org>; Fri, 28 Nov 2008 05:39:00 -0800 (PST) Received: from [75.68.119.237] (port=63069 helo=[192.168.15.102]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from <eburger at standardstrack.com>) id 1L63Yc-0000py-Dz; Fri, 28 Nov 2008 05:38:54 -0800 Message-Id: <F779DAF0-507D-4BB0-BA8C-C687F1C7BB30 at standardstrack.com> From: Eric Burger <eburger at standardstrack.com> To: Christer Holmberg <christer.holmberg at ericsson.com> In-Reply-To: <CA9998CD4A020D418654FCDEF4E707DF05C0F98E at esealmw113.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 28 Nov 2008 08:38:52 -0500 References: <94081CC4-F9BE-4651-BE3D-9D5CEDC3CA8D at standardstrack.com> <CA9998CD4A020D418654FCDEF4E707DF05C0F98E at esealmw113.eemea.ericsson.se> X-Mailer: Apple Mail (2.929.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.comX-Source: X-Source-Args: X-Source-Dir: Cc: SIP List <SIP at ietf.org>
Subject: Re: [Sip] INFO Framework - one pakage per INFO X-BeenThere: sip at ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol <sip.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request at ietf.org?subject=unsubscribe> List-Post: <mailto:sip at ietf.org> List-Help: <mailto:sip-request at ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request at ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1346600891==" Sender: sip-bounces at ietf.org Errors-To: sip-bounces at ietf.org
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 valueof 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. Re 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
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