Subject: [sipcore] draft-sparks-sipcore-name-addr-guidance-00

From: Robert Sparks <[email-masked]>
Date: Tue, 7 Jun 2016 15:48:33 -0500

I took a stab at writing the document discussed in this thread.

The result is at 
https://datatracker.ietf.org/doc/draft-sparks-sipcore-name-addr-guidance/

Let me know where it's horribly broken.

RjS

On 4/2/16 8:02 AM, Robert Sparks wrote:
>
>
> On 4/1/16 10:56 AM, Paul Kyzivat wrote:
>> On 3/31/16 6:08 PM, Robert Sparks wrote:
>>> Again, I don't think errata is the right way to skin this.
>>> <http://mailarchive.ietf.org/arch/msg/sipcore/OZN1Eey88Ksex8fia20fCZH_8qE> 
>>>
>>
>> I agree that when in doubt a draft is the better path.
>>
>> But in this case, I don't think a revision to 3261 would cover all 
>> the other documents out there that define header fields with this 
>> problem. It would still be necessary to update each of those 
>> documents to adopt the change.
>>
>> But we could do one document that updates 3261 *and* each of the 
>> other affected documents.
> That's what my message said.
>> Then, in the future, any new header field where this should apply 
>> could simply normatively reference this document.
>>
>>     Thanks,
>>     Paul
>>
>>> RjS
>>>
>>> On 3/31/16 4:48 PM, Dale R. Worley wrote:
>>>> Brett Tate <[email-masked]> writes:
>>>>> I agree; that was why I sent the following email in October 2013 
>>>>> while
>>>>> sipcore was working on similar errata for RFC 3325.  I used that
>>>>> email and
>>>>> aspects of the RFC 3325 errata to produce the recent errata for RFC
>>>>> 3515,
>>>>> RFC 5002, RFC 5318, RFC 5360, and RFC 5502.  I have not check any
>>>>> headers
>>>>> register with IANA since October 2013.
>>>>>
>>>>> http://www.ietf.org/mail-archive/web/sipcore/current/msg05731.html
>>>> Why don't we put in an erratum that edits RFC 3261 section 20.10.  The
>>>> old text is:
>>>>
>>>>     Even if the "display-name" is empty, the "name-addr" form MUST be
>>>>     used if the "addr-spec" contains a comma, semicolon, or question
>>>>     mark.  There may or may not be LWS between the display-name and 
>>>> the
>>>>     "<".
>>>>
>>>> The new text adds:
>>>>
>>>>     In any header field whose value syntax is
>>>>         (name-addr / addr-spec) *(SEMI generic-param)
>>>>     or
>>>>         (name-addr / addr-spec) *(SEMI generic-param)
>>>>             *(COMMA (name-addr / addr-spec) *(SEMI generic-param))
>>>>     the "addr-spec" alternative may not be used if its value would
>>>>     contain a comma, semicolon, or question mark.
>>>>
>>>> In a sense, that's what everybody *thinks* RFC 3261 requires.
>>>>
>>>> Dale
>>>>
>>>> _______________________________________________
>>>> sipcore mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>
>>> _______________________________________________
>>> sipcore mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>
>>
>> _______________________________________________
>> sipcore mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 8 Jun 2016 09:14:52 -0400

> Let me know where it's horribly broken.

It seems to do the job.

Do you think that the updates in section 3 can get away with not saying 
*where* that text is to be added in each of the documents?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 8 Jun 2016 13:40:48 +0000

Hi,

If we want to be really clear, we should say *UNESCAPED* comma, question
mark or semicolon.

Because, the characters could appear escaped in most parts of a SIP-URI,
but I don¹t think we should mandate usage of name-adde in such cases.

Regards,

Christer

---

From: Robert Sparks <[email-masked]>
Date: Wed, 8 Jun 2016 16:15:26 -0500

On 6/8/16 8:14 AM, Paul Kyzivat wrote:
> Do you think that the updates in section 3 can get away with not 
> saying *where* that text is to be added in each of the documents?
Yes.

I see nothing but trouble in trying to place them more specifically 
given what they do, and I don't see how they can be misinterpreted 
without such placement.

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 15 Jun 2016 21:57:09 -0400

This is a great step for cleaning up this mess!

If I'm not mistaken, RFC 3325 (P-Asserted-Identity and
P-Preferred-Identity) has a similar problem.  The grammar is

      PAssertedID = "P-Asserted-Identity" HCOLON PAssertedID-value
                      *(COMMA PAssertedID-value)
      PAssertedID-value = name-addr / addr-spec
      PPreferredID = "P-Preferred-Identity" HCOLON PPreferredID-value
                        *(COMMA PPreferredID-value)
      PPreferredID-value = name-addr / addr-spec

Since there are no header-field-parameters, semicolon is not
problematic, but comma is a problem, as is question mark.

Dale

---

From: Brett Tate <[email-masked]>
Date: Thu, 16 Jun 2016 07:02:51 -0400

Hi,

Yes; it is discussed within RFC 3325 errata (3744 and 3894).

Should it be mentioned within the draft?

> -----Original Message-----
> From: sipcore [mailto:[email-masked]] On Behalf Of Dale R.
Worley
> Sent: Wednesday, June 15, 2016 9:57 PM
> To: Robert Sparks
> Cc: [email-masked]
> Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-00
>
problematic, but
> comma is a problem, as is question mark.
>
> Dale
>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Thu, 16 Jun 2016 11:44:53 +0000

A reminder that RFC 3325 is an informational document, so I am not sure whether a standards track document can update an informational document. Anyone able to clarify?

Keith

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Brett Tate
Sent: 16 June 2016 12:03
To: Dale R. Worley; Robert Sparks; [email-masked]
Subject: Re: [sipcore] draft-sparks-sipcore-name-addr-guidance-00

Hi,

Worley
problematic, but

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 16 Jun 2016 12:25:44 -0400

"Drage, Keith (Nokia - GB)" <[email-masked]> writes:
> A reminder that RFC 3325 is an informational document, so I am not
> sure whether a standards track document can update an informational
> document. Anyone able to clarify?

I searched, but I couldn't find much guidance on what update documents
are or are not allowed to do in the BCP directory.

Dale