[sipcore] name-addr vs addr-spec requirements (was Re: [Technical Errata Reported] RFC5318 (4651))
Robert Sparks <rjsparks@nostrum.com> Wed, 30 March 2016 21:40 UTC
Return-Path: <rjsparks@nostrum.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1CB12D861 for <sipcore@ietfa.amsl.com>; Wed, 30 Mar 2016 14:40:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQYpZ8Eu8xGm for <sipcore@ietfa.amsl.com>; Wed, 30 Mar 2016 14:40:04 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5866A12D513 for <sipcore@ietf.org>; Wed, 30 Mar 2016 14:40:04 -0700 (PDT)
Received: from unnumerable.local (pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2ULe1um090081 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Wed, 30 Mar 2016 16:40:01 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-158-165.dllstx.fios.verizon.net [173.57.158.165] claimed to be unnumerable.local
To: sipcore@ietf.org
References: <20160329160146.E71EB180004@rfc-editor.org> <edea3ca213d3545652f43b4ea4a50fa8@mail.gmail.com> <56FBFAD5.1090806@ericsson.com> <B39D9D90-67F0-4A2C-89D9-F17A604B98CF@nostrum.com>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <56FC47B1.3090901@nostrum.com>
Date: Wed, 30 Mar 2016 16:40:01 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <B39D9D90-67F0-4A2C-89D9-F17A604B98CF@nostrum.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/sipcore/OZN1Eey88Ksex8fia20fCZH_8qE>
Cc: Ben Campbell <ben@nostrum.com>
Subject: [sipcore] name-addr vs addr-spec requirements (was Re: [Technical Errata Reported] RFC5318 (4651))
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Mar 2016 21:40:06 -0000
This cluster of errata (4650, 4651, 4652) are on the wrong edge of making a technical change from my perspective. It's a good technical change to make, and it _should_ have been stated as such in the documents the errata are filed against, but it is still a technical change. I would prefer the work to clarify the documents be done with a draft that goes through IETF LC rather than use errata. That draft could solve the problem this cluster points to much more generally, updating 3261 to require that _anywhere_ name-addr/addr-spec are used as alternates, name-addr MUST be used if comma, question mark, or semicolon appear. The text could leave an "unless explicitly specified otherwise" out. That draft could have a section capturing the places where we failed to say that so far, and update the relevant RFCs (the ones these errata point to) as well. RjS On 3/30/16 3:06 PM, Ben Campbell wrote: > (copying sipcore) > > On 30 Mar 2016, at 11:12, Gonzalo Camarillo wrote: > >> Hi Brett, >> >> I have the same comment as on the other document. I would talk about the >> name-addr form instead. Let's agree on the text we want to use for the >> three documents, since it is the same issue. >> >> Cheers, >> >> Gonzalo >> >> On 29/03/2016 7:06 PM, Brett Tate wrote: >>> Hi, >>> >>> My proposed resolution is similar to what occurred within RFC 3325 errata >>> (3744 and 3894). >>> >>>> -----Original Message----- >>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>> Sent: Tuesday, March 29, 2016 12:02 PM >>>> To: Jani.Hautakorpi@ericsson.com; Gonzalo.Camarillo@ericsson.com; >>>> iesg@ietf.org >>>> Cc: brett@broadsoft.com; rfc-editor@rfc-editor.org >>>> Subject: [Technical Errata Reported] RFC5318 (4651) >>>> >>>> The following errata report has been submitted for RFC5318, "The Session >>>> Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header)". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=5318&eid=4651 >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Brett Tate <brett@broadsoft.com> >>>> >>>> Section: 5 >>>> >>>> Original Text >>>> ------------- >>>> The members P-Header parameter MUST contain a cid-url, which is defined >>> in >>>> RFC 2392 [2]. >>>> >>>> Corrected Text >>>> -------------- >>>> The members P-Header parameter MUST contain a cid-url, which is defined >>> in >>>> RFC 2392 [2]. >>>> >>>> If the URI contains a comma, question mark or semicolon, the URI MUST be >>>> enclosed in angle brackets (< and >). >>>> >>>> Notes >>>> ----- >>>> Comma and semicolon can cause decode ambiguities when the header >>> contains >>>> addr-spec values instead of name-addr values. For consistency with RFC >>> 3261 >>>> section 20, the same bracket rule is indicated to resolve the ambiguity. >>>> >>>> Instructions: >>>> ------------- >>>> This erratum 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. >>>> >>>> -------------------------------------- >>>> RFC5318 (draft-hautakorpi-sipping-uri-list-handling-refused-03) >>>> -------------------------------------- >>>> Title : The Session Initiation Protocol (SIP) >>> P-Refused-URI- >>>> List Private-Header (P-Header) >>>> Publication Date : December 2008 >>>> Author(s) : J. Hautakorpi, G. Camarillo >>>> Category : INFORMATIONAL >>>> Source : IETF - NON WORKING GROUP >>>> Area : N/A >>>> Stream : IETF >>>> Verifying Party : IESG > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore
- Re: [sipcore] [Technical Errata Reported] RFC5318… Ben Campbell
- [sipcore] name-addr vs addr-spec requirements (wa… Robert Sparks