From john.elwell@siemens-enterprise.com Tue Apr 26 06:37:42 2011 Return-Path: X-Original-To: sipping@ietfa.amsl.com Delivered-To: sipping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD40E07A1; Tue, 26 Apr 2011 06:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.591 X-Spam-Level: X-Spam-Status: No, score=-104.591 tagged_above=-999 required=5 tests=[AWL=2.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59ydLdL9i9eF; Tue, 26 Apr 2011 06:37:42 -0700 (PDT) Received: from mail182.messagelabs.com (mail182.messagelabs.com [85.158.139.83]) by ietfa.amsl.com (Postfix) with SMTP id 7D09EE0793; Tue, 26 Apr 2011 06:37:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-10.tower-182.messagelabs.com!1303825059!5622519!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 28558 invoked from network); 26 Apr 2011 13:37:39 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-10.tower-182.messagelabs.com with SMTP; 26 Apr 2011 13:37:39 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 9054423F03E2; Tue, 26 Apr 2011 15:37:39 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 26 Apr 2011 15:37:39 +0200 From: "Elwell, John" To: "ietf@ietf.org" , "sipping@ietf.org" Date: Tue, 26 Apr 2011 15:37:37 +0200 Thread-Topic: Late comment on draft-ietf-sippping-sip-offeranswer-14 Thread-Index: AcwEFxtQP2WQ8OP3Tnm7SkCj3hScBA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Sipping] Late comment on draft-ietf-sippping-sip-offeranswer-14 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 13:37:42 -0000 I know last call finished already, but the following has just been brought = to my attention: In section 5.2.5 "Changing the o-line, except version number value, during the session is an error case. The behavior when receiving such a non-compliant offer/answer SDP body is implementation dependent. " I would content this is NOT an error situation, or at least not an error in= the case where a NEW session is being signalled. Consider a 3PCC situation along the lines described in section 7 of RFC 372= 5. The controlling B2BUA converts a session between UA A and UA B into a se= ssion between UA B and UA C. Prior to this conversion, UA B has received UA= A's SDP (SDP A). As a result of the conversion, UA B receives UA C's SDP (= SDP C). SDP C is likely to be completely different from SDP A. Therefore just a cha= nge of version number in the o-line is insufficient and would probably viol= ate RFC 3264. In particular, if SDP A has 2 m-lines and SDP C has only one = m-line, the change from 2 m-lines to 1 m-line is not permitted according to= RFC 3264. So although RFC 3725 talks about the controlling B2BUA adjusting= version numbers, that is insufficient in some cases. The text of 5.2.5 then goes on to say: "The behavior when receiving such a non-compliant offer/answer SDP body is implementation dependent." It is not clear what this fails to comply with. I can find nothing in RFC 3= 264 that stops you sending a new o-line if there is a new session. Yes, it = would be non-compliant if only modifying an existing session, but how does = the recipient know whether or not it is a new session, and therefore whethe= r or not it is valid? It then goes on to recommend use of Replaces in this situation (i.e. change= of session): "If a UA needs to negotiate a 'new' SDP session, it should use the INVITE/Replaces method." But Replaces is not feasible if the UA concerned does not support it (and h= ence "should", presumably). So there will still be cases where a controllin= g B2BUA is forced to change the o-line (not just the version) in order to c= omply with RFC 3264. So there needs to be a mechanism for changing to a 'new' session without re= lying on Replaces. As far as I can see, there is no standards track RFC tha= t forbids changing the o-line to achieve this, so this new Informational dr= aft should not attempt to make that change, and in particular should not do= so without proposing an alternative solution. A simple fix would be to delete the entire bullet beginning "In the o-line,= only the version number may change". John= From pkyzivat@cisco.com Tue Apr 26 14:42:10 2011 Return-Path: X-Original-To: sipping@ietfa.amsl.com Delivered-To: sipping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D13E0794 for ; Tue, 26 Apr 2011 14:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.455 X-Spam-Level: X-Spam-Status: No, score=-110.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCLa7aDt5w9M for ; Tue, 26 Apr 2011 14:42:09 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by ietfa.amsl.com (Postfix) with ESMTP id 91352E0792 for ; Tue, 26 Apr 2011 14:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3688; q=dns/txt; s=iport; t=1303854129; x=1305063729; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=yDvwBfx9q/ozftn+eFltEzxe5uH+GL0rcGFjAnDecZA=; b=RxITRoqX3m+BXl4zD0VjbdfZ3jzb1DvrPkiuu78ie1vZmP/yfRsrmmgr 7bMdLEkudAcD7xjpPzWgarsLfDfk/PylqVNTssDANWHDe9a0lAfAUXSX+ P6DvlUJQg4dHrcqTBuI5E5FTVdAFsY34UFtnk0dPDMwuBdEDsbHPNZF7T A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOI7t02tJXHA/2dsb2JhbAClZ3eIcKFUnQ6FdgSOQYQMijA X-IronPort-AV: E=Sophos;i="4.64,270,1301875200"; d="scan'208";a="231057648" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rtp-iport-1.cisco.com with ESMTP; 26 Apr 2011 21:41:54 +0000 Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p3QLfr0n006213 for ; Tue, 26 Apr 2011 21:41:53 GMT Message-ID: <4DB73C21.4040202@cisco.com> Date: Tue, 26 Apr 2011 17:41:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: sipping@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Sipping] Late comment on draft-ietf-sippping-sip-offeranswer-14 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 21:42:10 -0000 John, On 4/26/2011 9:37 AM, Elwell, John wrote: > I know last call finished already, but the following has just been brought to my attention: > > In section 5.2.5 > "Changing the o-line, > except version number value, during the session is an error case. > The behavior when receiving such a non-compliant offer/answer SDP > body is implementation dependent. " > I would content this is NOT an error situation, or at least not an error in the case where a NEW session is being signalled. > > Consider a 3PCC situation along the lines described in section 7 of RFC 3725. The controlling B2BUA converts a session between UA A and UA B into a session between UA B and UA C. Prior to this conversion, UA B has received UA A's SDP (SDP A). As a result of the conversion, UA B receives UA C's SDP (SDP C). > > SDP C is likely to be completely different from SDP A. Therefore just a change of version number in the o-line is insufficient and would probably violate RFC 3264. In particular, if SDP A has 2 m-lines and SDP C has only one m-line, the change from 2 m-lines to 1 m-line is not permitted according to RFC 3264. So although RFC 3725 talks about the controlling B2BUA adjusting version numbers, that is insufficient in some cases. It was precisely issues like this that led to the statements you are taking issue with. As I understand it, what you describe is not permitted - you can't reduce the number of m-lines, even by changing the o-line. This does put a burden on the 3pcc device - to patch up the SDP. I would actually prefer to have a change that would loosen up what can be done in this regard but it would be a normative change with pretty severe backward compatibility issues. > The text of 5.2.5 then goes on to say: > "The behavior when receiving such a non-compliant offer/answer SDP > body is implementation dependent." > It is not clear what this fails to comply with. I can find nothing in RFC 3264 that stops you sending a new o-line if there is a new session. Yes, it would be non-compliant if only modifying an existing session, but how does the recipient know whether or not it is a new session, and therefore whether or not it is valid? I think you are describing "SessionS Initiation Protocol", not the "Session Initiation Protocol". AFAIK you only get one session per invite-dialog-usage. > It then goes on to recommend use of Replaces in this situation (i.e. change of session): > "If a UA needs to negotiate a > 'new' SDP session, it should use the INVITE/Replaces method." > But Replaces is not feasible if the UA concerned does not support it (and hence "should", presumably). So there will still be cases where a controlling B2BUA is forced to change the o-line (not just the version) in order to comply with RFC 3264. > > So there needs to be a mechanism for changing to a 'new' session without relying on Replaces. As far as I can see, there is no standards track RFC that forbids changing the o-line to achieve this, so this new Informational draft should not attempt to make that change, and in particular should not do so without proposing an alternative solution. I think the mechanism requires a normative change to SIP. But I'm interested to hear what others think about this. > A simple fix would be to delete the entire bullet beginning "In the o-line, only the version number may change". Its awfully late - in the category of the "it ain't happening unless you lodge a complaint with the IESG". But regardless of that, it seems we have a difference of opinion here about what the standard is, and should discuss it. Thanks, Paul From john.elwell@siemens-enterprise.com Wed Apr 27 00:41:42 2011 Return-Path: X-Original-To: sipping@ietfa.amsl.com Delivered-To: sipping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAFCE06EE for ; Wed, 27 Apr 2011 00:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.633 X-Spam-Level: X-Spam-Status: No, score=-104.633 tagged_above=-999 required=5 tests=[AWL=1.966, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O5nYkiJ0xJjL for ; Wed, 27 Apr 2011 00:41:38 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id 45348E06D9 for ; Wed, 27 Apr 2011 00:41:38 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-7.tower-174.messagelabs.com!1303890096!18081488!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 1468 invoked from network); 27 Apr 2011 07:41:36 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-7.tower-174.messagelabs.com with SMTP; 27 Apr 2011 07:41:36 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id C33A41EB83E3; Wed, 27 Apr 2011 09:41:36 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 27 Apr 2011 09:41:36 +0200 From: "Elwell, John" To: Paul Kyzivat , "sipping@ietf.org" Date: Wed, 27 Apr 2011 09:41:35 +0200 Thread-Topic: [Sipping] Late comment on draft-ietf-sippping-sip-offeranswer-14 Thread-Index: AcwEWtZxUtJEmfh8Spi72RaEwbjGwwAUaEqA Message-ID: References: <4DB73C21.4040202@cisco.com> In-Reply-To: <4DB73C21.4040202@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Sipping] Late comment on draft-ietf-sippping-sip-offeranswer-14 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 07:41:43 -0000 =20 > -----Original Message----- > From: sipping-bounces@ietf.org=20 > [mailto:sipping-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 26 April 2011 22:42 > To: sipping@ietf.org > Subject: Re: [Sipping] Late comment on=20 > draft-ietf-sippping-sip-offeranswer-14 >=20 > John, >=20 > On 4/26/2011 9:37 AM, Elwell, John wrote: > > I know last call finished already, but the following has=20 > just been brought to my attention: > > > > In section 5.2.5 > > "Changing the o-line, > > except version number value, during the session is=20 > an error case. > > The behavior when receiving such a non-compliant=20 > offer/answer SDP > > body is implementation dependent. " > > I would content this is NOT an error situation, or at least=20 > not an error in the case where a NEW session is being signalled. > > > > Consider a 3PCC situation along the lines described in=20 > section 7 of RFC 3725. The controlling B2BUA converts a=20 > session between UA A and UA B into a session between UA B and=20 > UA C. Prior to this conversion, UA B has received UA A's SDP=20 > (SDP A). As a result of the conversion, UA B receives UA C's=20 > SDP (SDP C). > > > > SDP C is likely to be completely different from SDP A.=20 > Therefore just a change of version number in the o-line is=20 > insufficient and would probably violate RFC 3264. In=20 > particular, if SDP A has 2 m-lines and SDP C has only one=20 > m-line, the change from 2 m-lines to 1 m-line is not=20 > permitted according to RFC 3264. So although RFC 3725 talks=20 > about the controlling B2BUA adjusting version numbers, that=20 > is insufficient in some cases. >=20 > It was precisely issues like this that led to the statements you are=20 > taking issue with. >=20 > As I understand it, what you describe is not permitted - you can't=20 > reduce the number of m-lines, even by changing the o-line. [JRE] Where is that stated normatively? >=20 > This does put a burden on the 3pcc device - to patch up the SDP. [JRE] This MIGHT be feasible, but it goes way beyond just manipulating vers= ion numbers. Basically the B2BUA would have to retain state about which m-l= ines are in use in each leg of the call (i.e., to B and to C) and perform m= appings each time a SDP is passed through (e.g., the second m-line from B b= ecomes the third m-line to C and vice versa). I wonder how many implementat= ions do this today? > I would actually prefer to have a change that would loosen up=20 > what can=20 > be done in this regard but it would be a normative change with pretty=20 > severe backward compatibility issues. >=20 > > The text of 5.2.5 then goes on to say: > > "The behavior when receiving such a non-compliant offer/answer SDP > > body is implementation dependent." > > It is not clear what this fails to comply with. I can find=20 > nothing in RFC 3264 that stops you sending a new o-line if=20 > there is a new session. Yes, it would be non-compliant if=20 > only modifying an existing session, but how does the=20 > recipient know whether or not it is a new session, and=20 > therefore whether or not it is valid? >=20 > I think you are describing "SessionS Initiation Protocol", not the=20 > "Session Initiation Protocol". AFAIK you only get one session per=20 > invite-dialog-usage. [JRE] Again, where is that stated normatively? >=20 > > It then goes on to recommend use of Replaces in this=20 > situation (i.e. change of session): > > "If a UA needs to negotiate a > > 'new' SDP session, it should use the INVITE/Replaces method." > > But Replaces is not feasible if the UA concerned does not=20 > support it (and hence "should", presumably). So there will=20 > still be cases where a controlling B2BUA is forced to change=20 > the o-line (not just the version) in order to comply with RFC 3264. > > > > So there needs to be a mechanism for changing to a 'new'=20 > session without relying on Replaces. As far as I can see,=20 > there is no standards track RFC that forbids changing the=20 > o-line to achieve this, so this new Informational draft=20 > should not attempt to make that change, and in particular=20 > should not do so without proposing an alternative solution. >=20 > I think the mechanism requires a normative change to SIP. [JRE] That depends - it is unclear to me what normative statements are brok= en by starting a new session with a new o-line. John >=20 > But I'm interested to hear what others think about this. >=20 > > A simple fix would be to delete the entire bullet beginning=20 > "In the o-line, only the version number may change". >=20 > Its awfully late - in the category of the "it ain't happening=20 > unless you=20 > lodge a complaint with the IESG". >=20 > But regardless of that, it seems we have a difference of opinion here=20 > about what the standard is, and should discuss it. >=20 > Thanks, > Paul > _______________________________________________ > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP > = From keith.drage@alcatel-lucent.com Wed Apr 27 02:18:23 2011 Return-Path: X-Original-To: sipping@ietfa.amsl.com Delivered-To: sipping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D334AE071A for ; Wed, 27 Apr 2011 02:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.928 X-Spam-Level: X-Spam-Status: No, score=-105.928 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwcSx8-XoTmw for ; Wed, 27 Apr 2011 02:18:19 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8F984E0716 for ; Wed, 27 Apr 2011 02:18:19 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3R9HG8R025975 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 27 Apr 2011 11:18:15 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 27 Apr 2011 11:17:57 +0200 From: "DRAGE, Keith (Keith)" To: "Elwell, John" , Paul Kyzivat , "sipping@ietf.org" Date: Wed, 27 Apr 2011 11:17:55 +0200 Thread-Topic: [Sipping] Late comment on draft-ietf-sippping-sip-offeranswer-14 Thread-Index: AcwEWtZxUtJEmfh8Spi72RaEwbjGwwAUaEqAAAOUupA= Message-ID: References: <4DB73C21.4040202@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [Sipping] Late comment on draft-ietf-sippping-sip-offeranswer-14 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 09:18:23 -0000 What people should be doing and what people are doing as short cuts are two= different things. If a B2BUA (aka 3PCC) attempts to manipulate the SDP in any way shape or fo= rm, then it has to become responsible for the integrity of the SDP that res= ults. It cannot just merge media lines and hope it gets away with it. And I would not phrase that as patching up the SDP - the 3PCC has to become= the SDP protocol entity. After all, RFC 3725 that you reference for this s= cenario states: From here, new parties can be added, removed, transferred, and so on, as the controller sees fit. In many cases, the controller will be required to modify the SDP exchanged between the participants in order to affect these changes. In particular, the version number in the SDP will need to be changed by the controller in certain cases. If the controller should issue an SDP offer on its own (for example, to place a call on hold), it will need to increment the version number in the SDP offer. The other participant in the call will not know that the controller has done this, and any subsequent offer it generates will have the wrong version number as far as its peer is concerned. As a result, the controller will be required to modify the version number in SDP messages to match what the recipient is expecting. To me this clearly indicates that the controller has become responsible for= the SDP contents. Regards Keith > -----Original Message----- > From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On Behal= f > Of Elwell, John > Sent: 27 April 2011 08:42 > To: Paul Kyzivat; sipping@ietf.org > Subject: Re: [Sipping] Late comment on draft-ietf-sippping-sip- > offeranswer-14 >=20 >=20 >=20 > > -----Original Message----- > > From: sipping-bounces@ietf.org > > [mailto:sipping-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: 26 April 2011 22:42 > > To: sipping@ietf.org > > Subject: Re: [Sipping] Late comment on > > draft-ietf-sippping-sip-offeranswer-14 > > > > John, > > > > On 4/26/2011 9:37 AM, Elwell, John wrote: > > > I know last call finished already, but the following has > > just been brought to my attention: > > > > > > In section 5.2.5 > > > "Changing the o-line, > > > except version number value, during the session is > > an error case. > > > The behavior when receiving such a non-compliant > > offer/answer SDP > > > body is implementation dependent. " > > > I would content this is NOT an error situation, or at least > > not an error in the case where a NEW session is being signalled. > > > > > > Consider a 3PCC situation along the lines described in > > section 7 of RFC 3725. The controlling B2BUA converts a > > session between UA A and UA B into a session between UA B and > > UA C. Prior to this conversion, UA B has received UA A's SDP > > (SDP A). As a result of the conversion, UA B receives UA C's > > SDP (SDP C). > > > > > > SDP C is likely to be completely different from SDP A. > > Therefore just a change of version number in the o-line is > > insufficient and would probably violate RFC 3264. In > > particular, if SDP A has 2 m-lines and SDP C has only one > > m-line, the change from 2 m-lines to 1 m-line is not > > permitted according to RFC 3264. So although RFC 3725 talks > > about the controlling B2BUA adjusting version numbers, that > > is insufficient in some cases. > > > > It was precisely issues like this that led to the statements you are > > taking issue with. > > > > As I understand it, what you describe is not permitted - you can't > > reduce the number of m-lines, even by changing the o-line. > [JRE] Where is that stated normatively? >=20 >=20 > > > > This does put a burden on the 3pcc device - to patch up the SDP. > [JRE] This MIGHT be feasible, but it goes way beyond just manipulating > version numbers. Basically the B2BUA would have to retain state about > which m-lines are in use in each leg of the call (i.e., to B and to C) an= d > perform mappings each time a SDP is passed through (e.g., the second m- > line from B becomes the third m-line to C and vice versa). I wonder how > many implementations do this today? >=20 > > I would actually prefer to have a change that would loosen up > > what can > > be done in this regard but it would be a normative change with pretty > > severe backward compatibility issues. > > > > > The text of 5.2.5 then goes on to say: > > > "The behavior when receiving such a non-compliant offer/answer SDP > > > body is implementation dependent." > > > It is not clear what this fails to comply with. I can find > > nothing in RFC 3264 that stops you sending a new o-line if > > there is a new session. Yes, it would be non-compliant if > > only modifying an existing session, but how does the > > recipient know whether or not it is a new session, and > > therefore whether or not it is valid? > > > > I think you are describing "SessionS Initiation Protocol", not the > > "Session Initiation Protocol". AFAIK you only get one session per > > invite-dialog-usage. > [JRE] Again, where is that stated normatively? >=20 > > > > > It then goes on to recommend use of Replaces in this > > situation (i.e. change of session): > > > "If a UA needs to negotiate a > > > 'new' SDP session, it should use the INVITE/Replaces method." > > > But Replaces is not feasible if the UA concerned does not > > support it (and hence "should", presumably). So there will > > still be cases where a controlling B2BUA is forced to change > > the o-line (not just the version) in order to comply with RFC 3264. > > > > > > So there needs to be a mechanism for changing to a 'new' > > session without relying on Replaces. As far as I can see, > > there is no standards track RFC that forbids changing the > > o-line to achieve this, so this new Informational draft > > should not attempt to make that change, and in particular > > should not do so without proposing an alternative solution. > > > > I think the mechanism requires a normative change to SIP. > [JRE] That depends - it is unclear to me what normative statements are > broken by starting a new session with a new o-line. >=20 > John >=20 >=20 > > > > But I'm interested to hear what others think about this. > > > > > A simple fix would be to delete the entire bullet beginning > > "In the o-line, only the version number may change". > > > > Its awfully late - in the category of the "it ain't happening > > unless you > > lodge a complaint with the IESG". > > > > But regardless of that, it seems we have a difference of opinion here > > about what the standard is, and should discuss it. > > > > Thanks, > > Paul > > _______________________________________________ > > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > > > _______________________________________________ > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sip@ietf.org for new developments of core SIP From john.elwell@siemens-enterprise.com Wed Apr 27 05:36:55 2011 Return-Path: X-Original-To: sipping@ietfa.amsl.com Delivered-To: sipping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA38E0727 for ; Wed, 27 Apr 2011 05:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.818 X-Spam-Level: X-Spam-Status: No, score=-104.818 tagged_above=-999 required=5 tests=[AWL=1.781, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opxXgZ0-utlz for ; Wed, 27 Apr 2011 05:36:51 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id 7D2E9E0742 for ; Wed, 27 Apr 2011 05:36:50 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-4.tower-216.messagelabs.com!1303907809!3358223!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 21716 invoked from network); 27 Apr 2011 12:36:49 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-4.tower-216.messagelabs.com with SMTP; 27 Apr 2011 12:36:49 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 33EC21EB83E3; Wed, 27 Apr 2011 14:36:49 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 27 Apr 2011 14:36:49 +0200 From: "Elwell, John" To: "DRAGE, Keith (Keith)" , Paul Kyzivat , "sipping@ietf.org" Date: Wed, 27 Apr 2011 14:36:48 +0200 Thread-Topic: [Sipping] Late comment on draft-ietf-sippping-sip-offeranswer-14 Thread-Index: AcwEWtZxUtJEmfh8Spi72RaEwbjGwwAUaEqAAAOUupAABsKP4A== Message-ID: References: <4DB73C21.4040202@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Sipping] Late comment on draft-ietf-sippping-sip-offeranswer-14 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 12:36:55 -0000 =20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20 > Sent: 27 April 2011 10:18 > To: Elwell, John; Paul Kyzivat; sipping@ietf.org > Subject: RE: [Sipping] Late comment on=20 > draft-ietf-sippping-sip-offeranswer-14 >=20 > What people should be doing and what people are doing as=20 > short cuts are two different things. >=20 > If a B2BUA (aka 3PCC) attempts to manipulate the SDP in any=20 > way shape or form, then it has to become responsible for the=20 > integrity of the SDP that results. It cannot just merge media=20 > lines and hope it gets away with it. [JRE] Exactly, so it should do minimal manipulation, ideally none at all. S= o when B finds itself talking to A and then talking to C, B should receive = first of all A's SDP and then C's SDP - these will have different o-lines. = If the controller also generates its own SDP from time to time, e.g., for p= lacing a session on hold, this will put the version numbers on the two legs= out of step, and the controller will need to compensate for that - this is= the example given in RFC 3725. But manipulation beyond that should not be = necessary - it should just pass SDP through. >=20 > And I would not phrase that as patching up the SDP - the 3PCC=20 > has to become the SDP protocol entity. After all, RFC 3725=20 > that you reference for this scenario states: >=20 > From here, new parties can be added, removed, transferred,=20 > and so on, > as the controller sees fit. In many cases, the controller will be > required to modify the SDP exchanged between the participants in > order to affect these changes. In particular, the version=20 > number in > the SDP will need to be changed by the controller in certain cases. > If the controller should issue an SDP offer on its own=20 > (for example, > to place a call on hold), it will need to increment the version > number in the SDP offer. The other participant in the=20 > call will not > know that the controller has done this, and any subsequent offer it > generates will have the wrong version number as far as its peer is > concerned. As a result, the controller will be required to modify > the version number in SDP messages to match what the recipient is > expecting. [JRE] This example talks about modifying version numbers, but I would claim= that is not good enough. It would need to modify the rest of the o-line in= order to prevent the recipient receiving SDPs with different o-lines. But = I don't read that in RFC 3725. >=20 > To me this clearly indicates that the controller has become=20 > responsible for the SDP contents. [JRE] In my opinion the text of RFC 3725 is not clear - it talks about the = controller modifying SDP, and the particular example given just talks about= modifying the version number. Yet what Keith seems to be claiming is that = the controller does more than that - implying that the controller generates= its own SDP based on some information received in SDP from the remote part= y. John >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: sipping-bounces@ietf.org=20 > [mailto:sipping-bounces@ietf.org] On Behalf > > Of Elwell, John > > Sent: 27 April 2011 08:42 > > To: Paul Kyzivat; sipping@ietf.org > > Subject: Re: [Sipping] Late comment on draft-ietf-sippping-sip- > > offeranswer-14 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: sipping-bounces@ietf.org > > > [mailto:sipping-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > Sent: 26 April 2011 22:42 > > > To: sipping@ietf.org > > > Subject: Re: [Sipping] Late comment on > > > draft-ietf-sippping-sip-offeranswer-14 > > > > > > John, > > > > > > On 4/26/2011 9:37 AM, Elwell, John wrote: > > > > I know last call finished already, but the following has > > > just been brought to my attention: > > > > > > > > In section 5.2.5 > > > > "Changing the o-line, > > > > except version number value, during the session is > > > an error case. > > > > The behavior when receiving such a non-compliant > > > offer/answer SDP > > > > body is implementation dependent. " > > > > I would content this is NOT an error situation, or at least > > > not an error in the case where a NEW session is being signalled. > > > > > > > > Consider a 3PCC situation along the lines described in > > > section 7 of RFC 3725. The controlling B2BUA converts a > > > session between UA A and UA B into a session between UA B and > > > UA C. Prior to this conversion, UA B has received UA A's SDP > > > (SDP A). As a result of the conversion, UA B receives UA C's > > > SDP (SDP C). > > > > > > > > SDP C is likely to be completely different from SDP A. > > > Therefore just a change of version number in the o-line is > > > insufficient and would probably violate RFC 3264. In > > > particular, if SDP A has 2 m-lines and SDP C has only one > > > m-line, the change from 2 m-lines to 1 m-line is not > > > permitted according to RFC 3264. So although RFC 3725 talks > > > about the controlling B2BUA adjusting version numbers, that > > > is insufficient in some cases. > > > > > > It was precisely issues like this that led to the=20 > statements you are > > > taking issue with. > > > > > > As I understand it, what you describe is not permitted - you can't > > > reduce the number of m-lines, even by changing the o-line. > > [JRE] Where is that stated normatively? > >=20 > >=20 > > > > > > This does put a burden on the 3pcc device - to patch up the SDP. > > [JRE] This MIGHT be feasible, but it goes way beyond just=20 > manipulating > > version numbers. Basically the B2BUA would have to retain=20 > state about > > which m-lines are in use in each leg of the call (i.e., to=20 > B and to C) and > > perform mappings each time a SDP is passed through (e.g.,=20 > the second m- > > line from B becomes the third m-line to C and vice versa).=20 > I wonder how > > many implementations do this today? > >=20 > > > I would actually prefer to have a change that would loosen up > > > what can > > > be done in this regard but it would be a normative change=20 > with pretty > > > severe backward compatibility issues. > > > > > > > The text of 5.2.5 then goes on to say: > > > > "The behavior when receiving such a non-compliant=20 > offer/answer SDP > > > > body is implementation dependent." > > > > It is not clear what this fails to comply with. I can find > > > nothing in RFC 3264 that stops you sending a new o-line if > > > there is a new session. Yes, it would be non-compliant if > > > only modifying an existing session, but how does the > > > recipient know whether or not it is a new session, and > > > therefore whether or not it is valid? > > > > > > I think you are describing "SessionS Initiation Protocol", not the > > > "Session Initiation Protocol". AFAIK you only get one session per > > > invite-dialog-usage. > > [JRE] Again, where is that stated normatively? > >=20 > > > > > > > It then goes on to recommend use of Replaces in this > > > situation (i.e. change of session): > > > > "If a UA needs to negotiate a > > > > 'new' SDP session, it should use the=20 > INVITE/Replaces method." > > > > But Replaces is not feasible if the UA concerned does not > > > support it (and hence "should", presumably). So there will > > > still be cases where a controlling B2BUA is forced to change > > > the o-line (not just the version) in order to comply with=20 > RFC 3264. > > > > > > > > So there needs to be a mechanism for changing to a 'new' > > > session without relying on Replaces. As far as I can see, > > > there is no standards track RFC that forbids changing the > > > o-line to achieve this, so this new Informational draft > > > should not attempt to make that change, and in particular > > > should not do so without proposing an alternative solution. > > > > > > I think the mechanism requires a normative change to SIP. > > [JRE] That depends - it is unclear to me what normative=20 > statements are > > broken by starting a new session with a new o-line. > >=20 > > John > >=20 > >=20 > > > > > > But I'm interested to hear what others think about this. > > > > > > > A simple fix would be to delete the entire bullet beginning > > > "In the o-line, only the version number may change". > > > > > > Its awfully late - in the category of the "it ain't happening > > > unless you > > > lodge a complaint with the IESG". > > > > > > But regardless of that, it seems we have a difference of=20 > opinion here > > > about what the standard is, and should discuss it. > > > > > > Thanks, > > > Paul > > > _______________________________________________ > > > Sipping mailing list =20 > https://www.ietf.org/mailman/listinfo/sipping > > > This list is for NEW development of the application of SIP > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sip@ietf.org for new developments of core SIP > > > > > _______________________________________________ > > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sip@ietf.org for new developments of core SIP > = From rjsparks@nostrum.com Wed Apr 27 08:44:47 2011 Return-Path: X-Original-To: sipping@ietfa.amsl.com Delivered-To: sipping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71488E06F7; Wed, 27 Apr 2011 08:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0U3eKRZt4mY; Wed, 27 Apr 2011 08:44:46 -0700 (PDT) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by ietfa.amsl.com (Postfix) with ESMTP id BADE0E06CE; Wed, 27 Apr 2011 08:44:46 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p3RFhLZm060407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Apr 2011 10:43:25 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: Date: Wed, 27 Apr 2011 10:43:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2DAC5182-ACDF-4DD9-9B7E-256D00C3E51E@nostrum.com> References: To: "Elwell, John" X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "rai-ads@tools.ietf.org ADs" , SIPCORE Chairs , mmusic-chairs@tools.ietf.org, sipping LIST , IETF Discussion Subject: Re: [Sipping] Late comment on draft-ietf-sippping-sip-offeranswer-14 X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 15:44:47 -0000 I believe the current text in the draft reflects the discussion from = 2007 at To summarize, while we think there may be implementations that interpret = a change of session-id as a session reset, RFC3264 doesn't support the notion. The top-level assumption of 3264 is = that there is one SDP session associated with a SIP dialog. (See in particular: and ) The thread explores places where some folks would like to things to be = different, but those things will need normative updates, probably to more than one RFC. I believe the text in the draft is consistent with what our current = specs say. For the normative updates we would need to make for this particular = topic, I think=20 restarting the debate on the RAI list (with pointers to SIPCORE and = MMUSIC) is the right thing to do. =09 RjS On Apr 26, 2011, at 8:37 AM, Elwell, John wrote: > I know last call finished already, but the following has just been = brought to my attention: >=20 > In section 5.2.5 > "Changing the o-line, > except version number value, during the session is an error case. > The behavior when receiving such a non-compliant offer/answer SDP > body is implementation dependent. " > I would content this is NOT an error situation, or at least not an = error in the case where a NEW session is being signalled. >=20 > Consider a 3PCC situation along the lines described in section 7 of = RFC 3725. The controlling B2BUA converts a session between UA A and UA B = into a session between UA B and UA C. Prior to this conversion, UA B has = received UA A's SDP (SDP A). As a result of the conversion, UA B = receives UA C's SDP (SDP C). >=20 > SDP C is likely to be completely different from SDP A. Therefore just = a change of version number in the o-line is insufficient and would = probably violate RFC 3264. In particular, if SDP A has 2 m-lines and SDP = C has only one m-line, the change from 2 m-lines to 1 m-line is not = permitted according to RFC 3264. So although RFC 3725 talks about the = controlling B2BUA adjusting version numbers, that is insufficient in = some cases. >=20 > The text of 5.2.5 then goes on to say: > "The behavior when receiving such a non-compliant offer/answer SDP > body is implementation dependent." > It is not clear what this fails to comply with. I can find nothing in = RFC 3264 that stops you sending a new o-line if there is a new session. = Yes, it would be non-compliant if only modifying an existing session, = but how does the recipient know whether or not it is a new session, and = therefore whether or not it is valid? >=20 > It then goes on to recommend use of Replaces in this situation (i.e. = change of session): > "If a UA needs to negotiate a > 'new' SDP session, it should use the INVITE/Replaces method." > But Replaces is not feasible if the UA concerned does not support it = (and hence "should", presumably). So there will still be cases where a = controlling B2BUA is forced to change the o-line (not just the version) = in order to comply with RFC 3264. >=20 > So there needs to be a mechanism for changing to a 'new' session = without relying on Replaces. As far as I can see, there is no standards = track RFC that forbids changing the o-line to achieve this, so this new = Informational draft should not attempt to make that change, and in = particular should not do so without proposing an alternative solution. >=20 > A simple fix would be to delete the entire bullet beginning "In the = o-line, only the version number may change". >=20 > John > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From wwwrun@rfc-editor.org Wed Apr 27 16:34:12 2011 Return-Path: X-Original-To: sipping@ietfa.amsl.com Delivered-To: sipping@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD94E07AB; Wed, 27 Apr 2011 16:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.028 X-Spam-Level: X-Spam-Status: No, score=-102.028 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDdDLJaLK6Iv; Wed, 27 Apr 2011 16:34:12 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 3757CE0824; Wed, 27 Apr 2011 16:34:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 20410E0791; Wed, 27 Apr 2011 16:34:12 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110427233412.20410E0791@rfc-editor.org> Date: Wed, 27 Apr 2011 16:34:12 -0700 (PDT) Cc: sipping@ietf.org, rfc-editor@rfc-editor.org Subject: [Sipping] RFC 6157 on IPv6 Transition in the Session Initiation Protocol (SIP) X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 23:34:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6157 Title: IPv6 Transition in the Session Initiation Protocol (SIP) Author: G. Camarillo, K. El Malki, V. Gurbani Status: Standards Track Stream: IETF Date: April 2011 Mailbox: Gonzalo.Camarillo@ericsson.com, karim@athonet.com, vkg@bell-labs.com Pages: 15 Characters: 32492 Updates: RFC3264 I-D Tag: draft-ietf-sipping-v6-transition-07.txt URL: http://www.rfc-editor.org/rfc/rfc6157.txt This document describes how the IPv4 Session Initiation Protocol (SIP) user agents can communicate with IPv6 SIP user agents (and vice versa) at the signaling layer as well as exchange media once the session has been successfully set up. Both single- and dual-stack (i.e., IPv4-only and IPv4/IPv6) user agents are considered. [STANDARDS-TRACK] This document is a product of the Session Initiation Proposal Investigation Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC