From wwwrun@rfc-editor.org  Thu Mar  1 13:44:56 2012
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: martini@ietfa.amsl.com
Delivered-To: martini@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44BC21F8A2A for <martini@ietfa.amsl.com>; Thu,  1 Mar 2012 13:44:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.311
X-Spam-Level: 
X-Spam-Status: No, score=-102.311 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pC7R54zgTnP8 for <martini@ietfa.amsl.com>; Thu,  1 Mar 2012 13:44:55 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2CF21E8036 for <martini@ietf.org>; Thu,  1 Mar 2012 13:44:55 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id CC43BB1E004; Thu,  1 Mar 2012 13:39:13 -0800 (PST)
To: adam@nostrum.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, Bernard_Aboba@hotmail.com, spencer@wonderhamster.org
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20120301213913.CC43BB1E004@rfc-editor.org>
Date: Thu,  1 Mar 2012 13:39:13 -0800 (PST)
Cc: martini@ietf.org, rfc-editor@rfc-editor.org
Subject: [martini] [Technical Errata Reported] RFC6140 (3144)
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/martini>
List-Post: <mailto:martini@ietf.org>
List-Help: <mailto:martini-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2012 21:44:56 -0000

The following errata report has been submitted for RFC6140,
"Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6140&eid=3144

--------------------------------------
Type: Technical
Reported by: David Hancock <d.hancock@cablelabs.com>

Section: 5.2

Original Text
-------------
<none -- new text being added>

Corrected Text
--------------
<Insert following new paragraph between existing 2nd and 3rd paragraph>

The registrar MUST populate the Contact header field of the 200 (OK) response
to REGISTER only with the explicitly registered Contact URIs identified in the
REGISTER request (i.e., for bulk number registration, the Contact URIs
containing the “bnc” parameter). The Contact header field of the 200 (OK)
response MUST NOT contain the multiple contact addresses that are implicitly
created by the bulk number registration procedure. 

Notes
-----
The proposed text clarifies how the MUST statement in RFC 3261 section 10.3 item-8 applies in the case of bulk number registration.

RFC 3261 section 10.3 item-8 says ...
8. The registrar returns a 200 (OK) response.  The response MUST
   contain Contact header field values enumerating all current
   bindings.  <... text deleted...>

For bulk number registration, this means that the Contact header field in the 200 (OK) response to REGISTER contains the Contact URI with the "bnc" parameter, and not the multiple derived contact URIs that are bound to the multiple E.164 numbers associated with the registering PBX.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6140 (draft-ietf-martini-gin-13)
--------------------------------------
Title               : Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)
Publication Date    : March 2011
Author(s)           : A.B. Roach
Category            : PROPOSED STANDARD
Source              : Multiple AoR reachabiliTy InformatioN Indication
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

From adam@nostrum.com  Thu Mar  1 14:09:02 2012
Return-Path: <adam@nostrum.com>
X-Original-To: martini@ietfa.amsl.com
Delivered-To: martini@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A5121E82FD for <martini@ietfa.amsl.com>; Thu,  1 Mar 2012 14:09:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.338
X-Spam-Level: 
X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHV5UlRiQ5Nc for <martini@ietfa.amsl.com>; Thu,  1 Mar 2012 14:09:01 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1D721E8018 for <martini@ietf.org>; Thu,  1 Mar 2012 14:09:01 -0800 (PST)
Received: from dn3-228.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 q21M8s8d043911 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 1 Mar 2012 16:08:55 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <4F4FF375.60607@nostrum.com>
Date: Thu, 01 Mar 2012 16:08:53 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: RFC Errata System <rfc-editor@rfc-editor.org>
References: <20120301213913.CC43BB1E004@rfc-editor.org>
In-Reply-To: <20120301213913.CC43BB1E004@rfc-editor.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: gonzalo.camarillo@ericsson.com, martini@ietf.org, rjsparks@nostrum.com
Subject: Re: [martini] [Technical Errata Reported] RFC6140 (3144)
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/martini>
List-Post: <mailto:martini@ietf.org>
List-Help: <mailto:martini-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Mar 2012 22:09:02 -0000

This issue has already caused substantial confusion. The behavior that 
David proposes was clearly the intention of the working group, based on 
the discussions that went into development of the document. I believe 
the proper classification (based on the criteria published at 
http://www.ietf.org/iesg/statement/errata-processing.html) is "Approved."

/a

On 3/1/12 3:39 PM, RFC Errata System wrote:
> The following errata report has been submitted for RFC6140,
> "Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6140&eid=3144
>
> --------------------------------------
> Type: Technical
> Reported by: David Hancock<d.hancock@cablelabs.com>
>
> Section: 5.2
>
> Original Text
> -------------
> <none -- new text being added>
>
> Corrected Text
> --------------
> <Insert following new paragraph between existing 2nd and 3rd paragraph>
>
> The registrar MUST populate the Contact header field of the 200 (OK) response
> to REGISTER only with the explicitly registered Contact URIs identified in the
> REGISTER request (i.e., for bulk number registration, the Contact URIs
> containing the “bnc” parameter). The Contact header field of the 200 (OK)
> response MUST NOT contain the multiple contact addresses that are implicitly
> created by the bulk number registration procedure.
>
> Notes
> -----
> The proposed text clarifies how the MUST statement in RFC 3261 section 10.3 item-8 applies in the case of bulk number registration.
>
> RFC 3261 section 10.3 item-8 says ...
> 8. The registrar returns a 200 (OK) response.  The response MUST
>     contain Contact header field values enumerating all current
>     bindings.<... text deleted...>
>
> For bulk number registration, this means that the Contact header field in the 200 (OK) response to REGISTER contains the Contact URI with the "bnc" parameter, and not the multiple derived contact URIs that are bound to the multiple E.164 numbers associated with the registering PBX.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6140 (draft-ietf-martini-gin-13)
> --------------------------------------
> Title               : Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP)
> Publication Date    : March 2011
> Author(s)           : A.B. Roach
> Category            : PROPOSED STANDARD
> Source              : Multiple AoR reachabiliTy InformatioN Indication
> Area                : Real-time Applications and Infrastructure
> Stream              : IETF
> Verifying Party     : IESG


From spencer@wonderhamster.org  Tue Mar  6 10:16:21 2012
Return-Path: <spencer@wonderhamster.org>
X-Original-To: martini@ietfa.amsl.com
Delivered-To: martini@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42F021F88B8 for <martini@ietfa.amsl.com>; Tue,  6 Mar 2012 10:16:21 -0800 (PST)
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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlRLwKHK6GUt for <martini@ietfa.amsl.com>; Tue,  6 Mar 2012 10:16:21 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id D46B021F8842 for <martini@ietf.org>; Tue,  6 Mar 2012 10:16:20 -0800 (PST)
Received: from [10.252.1.44] (host225-111.cablelabs.com [192.160.73.225]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MHoSj-1S6MVW3zTh-003LtW; Tue, 06 Mar 2012 13:16:18 -0500
Message-ID: <4F565466.5070600@wonderhamster.org>
Date: Tue, 06 Mar 2012 12:16:06 -0600
From: Spencer Dawkins <spencer@wonderhamster.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Adam Roach <adam@nostrum.com>
References: <20120301213913.CC43BB1E004@rfc-editor.org> <4F4FF375.60607@nostrum.com>
In-Reply-To: <4F4FF375.60607@nostrum.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V02:K0:LCdrqgp2tHmF9iwULuuUwfOOWb3pLRawvmRQUJAhZG5 ZcpMmDwpLY1qZlG3w5u0PxVRJcQU1oraX2keyMeq3i5TgaZ9Pt sY0haFNlbt/lFV51CfF4/N6fFbH7siioqw/O0aTlJN/FKCM+tE 7k2jiKOvppobD0V2J4mFcPHvQuR1ydukovGD0bhhPGX1XYeZqf AzqLaaKp8FHFuzCrOXDCQ6f8rZ6fmvbhZhCL4gJKJIKX7FpQiq S98IFdwocKs5J8bvR+uhd48WyqTjigoULWSubUR2nSLxbUnF7D AcQ0hyLa6B9jCW7CP8rcDcF/UqATD62bP1cAamomr+reupCsKi HOD/bkXzS933SKMVXtQ7tyQMd/cJC6lqQTu5bgUuP
Cc: gonzalo.camarillo@ericsson.com, martini@ietf.org, RFC Errata System <rfc-editor@rfc-editor.org>, rjsparks@nostrum.com
Subject: Re: [martini] [Technical Errata Reported] RFC6140 (3144)
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/martini>
List-Post: <mailto:martini@ietf.org>
List-Help: <mailto:martini-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2012 18:16:22 -0000

On 3/1/2012 4:08 PM, Adam Roach wrote:
> This issue has already caused substantial confusion. The behavior that
> David proposes was clearly the intention of the working group, based on
> the discussions that went into development of the document. I believe
> the proper classification (based on the criteria published at
> http://www.ietf.org/iesg/statement/errata-processing.html) is "Approved."
>
> /a

Adam, I agree ...

Gonzalo, I'm looking at 
http://www.ietf.org/iesg/statement/errata-processing.html, and it looks 
like the IESG would be evaluating this, since the MARTINI working group 
has closed.

Do the (former) chairs need to do anything, except possibly say, "we 
agree with Adam"?

It would be helpful for the SIPconnectIT discussions at SIP Forum to 
know whether this errata is approved (they're looking at SIPconnect 
interop test cases, and CableLabs has already identified this issue in 
interop testing).

Thanks,

Spencer

> On 3/1/12 3:39 PM, RFC Errata System wrote:
>> The following errata report has been submitted for RFC6140,
>> "Registration for Multiple Phone Numbers in the Session Initiation
>> Protocol (SIP)".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=6140&eid=3144
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: David Hancock<d.hancock@cablelabs.com>
>>
>> Section: 5.2
>>
>> Original Text
>> -------------
>> <none -- new text being added>
>>
>> Corrected Text
>> --------------
>> <Insert following new paragraph between existing 2nd and 3rd paragraph>
>>
>> The registrar MUST populate the Contact header field of the 200 (OK)
>> response
>> to REGISTER only with the explicitly registered Contact URIs
>> identified in the
>> REGISTER request (i.e., for bulk number registration, the Contact URIs
>> containing the “bnc” parameter). The Contact header field of the 200 (OK)
>> response MUST NOT contain the multiple contact addresses that are
>> implicitly
>> created by the bulk number registration procedure.
>>
>> Notes
>> -----
>> The proposed text clarifies how the MUST statement in RFC 3261 section
>> 10.3 item-8 applies in the case of bulk number registration.
>>
>> RFC 3261 section 10.3 item-8 says ...
>> 8. The registrar returns a 200 (OK) response. The response MUST
>> contain Contact header field values enumerating all current
>> bindings.<... text deleted...>
>>
>> For bulk number registration, this means that the Contact header field
>> in the 200 (OK) response to REGISTER contains the Contact URI with the
>> "bnc" parameter, and not the multiple derived contact URIs that are
>> bound to the multiple E.164 numbers associated with the registering PBX.
>>
>> Instructions:
>> -------------
>> This errata is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC6140 (draft-ietf-martini-gin-13)
>> --------------------------------------
>> Title : Registration for Multiple Phone Numbers in the Session
>> Initiation Protocol (SIP)
>> Publication Date : March 2011
>> Author(s) : A.B. Roach
>> Category : PROPOSED STANDARD
>> Source : Multiple AoR reachabiliTy InformatioN Indication
>> Area : Real-time Applications and Infrastructure
>> Stream : IETF
>> Verifying Party : IESG
>
>


From gonzalo.camarillo@ericsson.com  Sun Mar 18 00:48:19 2012
Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: martini@ietfa.amsl.com
Delivered-To: martini@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F09121F85C7 for <martini@ietfa.amsl.com>; Sun, 18 Mar 2012 00:48:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.346
X-Spam-Level: 
X-Spam-Status: No, score=-110.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAkPFntAotVN for <martini@ietfa.amsl.com>; Sun, 18 Mar 2012 00:48:18 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 263EA21F85C5 for <martini@ietf.org>; Sun, 18 Mar 2012 00:48:17 -0700 (PDT)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-bb-4f65933fb19a
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id ED.E7.27041.F33956F4; Sun, 18 Mar 2012 08:48:15 +0100 (CET)
Received: from [131.160.126.134] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Sun, 18 Mar 2012 08:48:15 +0100
Message-ID: <4F65933E.9040506@ericsson.com>
Date: Sun, 18 Mar 2012 09:48:14 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Spencer Dawkins <spencer@wonderhamster.org>
References: <20120301213913.CC43BB1E004@rfc-editor.org> <4F4FF375.60607@nostrum.com> <4F565466.5070600@wonderhamster.org>
In-Reply-To: <4F565466.5070600@wonderhamster.org>
X-Enigmail-Version: 1.3.4
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Tue, 20 Mar 2012 13:45:37 -0700
Cc: "martini@ietf.org" <martini@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>, "rjsparks@nostrum.com" <rjsparks@nostrum.com>
Subject: Re: [martini] [Technical Errata Reported] RFC6140 (3144)
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/martini>
List-Post: <mailto:martini@ietf.org>
List-Help: <mailto:martini-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Mar 2012 07:48:19 -0000

Hi Spencer,

no, you do not have anything else (beyond saying you agree with Adam).
We will "verify" the erratum so that everybody can see it is correct.

Thanks,

Gonzalo

On 06/03/2012 8:16 PM, Spencer Dawkins wrote:
> On 3/1/2012 4:08 PM, Adam Roach wrote:
>> This issue has already caused substantial confusion. The behavior that
>> David proposes was clearly the intention of the working group, based on
>> the discussions that went into development of the document. I believe
>> the proper classification (based on the criteria published at
>> http://www.ietf.org/iesg/statement/errata-processing.html) is "Approved."
>>
>> /a
> 
> Adam, I agree ...
> 
> Gonzalo, I'm looking at 
> http://www.ietf.org/iesg/statement/errata-processing.html, and it looks 
> like the IESG would be evaluating this, since the MARTINI working group 
> has closed.
> 
> Do the (former) chairs need to do anything, except possibly say, "we 
> agree with Adam"?
> 
> It would be helpful for the SIPconnectIT discussions at SIP Forum to 
> know whether this errata is approved (they're looking at SIPconnect 
> interop test cases, and CableLabs has already identified this issue in 
> interop testing).
> 
> Thanks,
> 
> Spencer
> 
>> On 3/1/12 3:39 PM, RFC Errata System wrote:
>>> The following errata report has been submitted for RFC6140,
>>> "Registration for Multiple Phone Numbers in the Session Initiation
>>> Protocol (SIP)".
>>>
>>> --------------------------------------
>>> You may review the report below and at:
>>> http://www.rfc-editor.org/errata_search.php?rfc=6140&eid=3144
>>>
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: David Hancock<d.hancock@cablelabs.com>
>>>
>>> Section: 5.2
>>>
>>> Original Text
>>> -------------
>>> <none -- new text being added>
>>>
>>> Corrected Text
>>> --------------
>>> <Insert following new paragraph between existing 2nd and 3rd paragraph>
>>>
>>> The registrar MUST populate the Contact header field of the 200 (OK)
>>> response
>>> to REGISTER only with the explicitly registered Contact URIs
>>> identified in the
>>> REGISTER request (i.e., for bulk number registration, the Contact URIs
>>> containing the “bnc” parameter). The Contact header field of the 200 (OK)
>>> response MUST NOT contain the multiple contact addresses that are
>>> implicitly
>>> created by the bulk number registration procedure.
>>>
>>> Notes
>>> -----
>>> The proposed text clarifies how the MUST statement in RFC 3261 section
>>> 10.3 item-8 applies in the case of bulk number registration.
>>>
>>> RFC 3261 section 10.3 item-8 says ...
>>> 8. The registrar returns a 200 (OK) response. The response MUST
>>> contain Contact header field values enumerating all current
>>> bindings.<... text deleted...>
>>>
>>> For bulk number registration, this means that the Contact header field
>>> in the 200 (OK) response to REGISTER contains the Contact URI with the
>>> "bnc" parameter, and not the multiple derived contact URIs that are
>>> bound to the multiple E.164 numbers associated with the registering PBX.
>>>
>>> Instructions:
>>> -------------
>>> This errata is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party (IESG)
>>> can log in to change the status and edit the report, if necessary.
>>>
>>> --------------------------------------
>>> RFC6140 (draft-ietf-martini-gin-13)
>>> --------------------------------------
>>> Title : Registration for Multiple Phone Numbers in the Session
>>> Initiation Protocol (SIP)
>>> Publication Date : March 2011
>>> Author(s) : A.B. Roach
>>> Category : PROPOSED STANDARD
>>> Source : Multiple AoR reachabiliTy InformatioN Indication
>>> Area : Real-time Applications and Infrastructure
>>> Stream : IETF
>>> Verifying Party : IESG
>>
>>
>