[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