Subject: Re: [sipcore] [Editorial Errata Reported] RFC3515 (4898)

From: "Ben Campbell" <[email-masked]>
Date: Tue, 03 Jan 2017 11:54:17 -0600

Does anyone have thoughts on this errata report?

Thanks!

Ben.

On 3 Jan 2017, at 11:50, RFC Errata System wrote:

> The following errata report has been submitted for RFC3515,
> "The Session Initiation Protocol (SIP) Refer Method".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3515&eid=4898
>
> --------------------------------------
> Type: Editorial
> Reported by: Marianne MOHALI <[email-masked]>
>
> Section: 2.1
>
> Original Text
> -------------
> Refer-To: <sip:[email-masked]?Accept-Contact=sip:bobsdesk.
>        biloxi.example.net&Call-ID%3D55432%40alicepc.atlanta.example.com>
>
> Corrected Text
> --------------
> Refer-To: <sip:[email-masked]?Accept-Contact=sip:bobsdesk.
>        biloxi.example.net&Call-ID=55432%40alicepc.atlanta.example.com>
>
> Notes
> -----
> The "=" between the header name (hname) and the value (hvalue) in the 
> headers component of the URI does not have to be in the percent-coded 
> format as part of the ABNF of the headers component defined in 
> RFC3261:
> sip:user:password@host:port;uri-parameters?headers
> headers         =  "?" header *( "&" header )
> header          =  hname "=" hvalue
> hname           =  1*( hnv-unreserved / unreserved / escaped )
> hvalue          =  *( hnv-unreserved / unreserved / escaped )
> hnv-unreserved  =  "[" / "]" / "/" / "?" / ":" / "+" / "$"
>
> 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
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC3515 (draft-ietf-sip-refer-07)
> --------------------------------------
> Title               : The Session Initiation Protocol (SIP) Refer 
> Method
> Publication Date    : April 2003
> Author(s)           : R. Sparks
> Category            : PROPOSED STANDARD
> Source              : Session Initiation Protocol
> Area                : Real-time Applications and Infrastructure
> Stream              : IETF
> Verifying Party     : IESG

---

From: Robert Sparks <[email-masked]>
Date: Tue, 3 Jan 2017 12:20:34 -0600

Marianne - why do you think this is important?

I'll go do the work to verify that your read that the particular '=' you 
point to is not necessary to encode, but even it that's correct, it's 
still allowed to encode it. I don't see how making the change you 
propose with the errata will help anyone?

RjS

On 1/3/17 11:54 AM, Ben Campbell wrote:
>> format as part of the ABNF of the headers component defined in RFC3261:
>> Title               : The Session Initiation Protocol (SIP) Refer Method

---

From: Robert Sparks <[email-masked]>
Date: Tue, 3 Jan 2017 12:29:45 -0600

Eh - nevermind - Marianne's point is that escaping that particulear "=" 
_isn't_ allowed by the ABNF (shown by what she quotes).

So, this is an bug in an example, and the error doesn't affect the 
specification. This one should go into 'hold for document update'.

RjS

On 1/3/17 12:20 PM, Robert Sparks wrote:
> I'll go do the work to verify that your read that the particular '=' 
> you point to is not necessary to encode, but even it that's correct, 
> it's still allowed to encode it. I don't see how making the change you 
>>> The "=" between the header name (hname) and the value (hvalue) in 
>>> the headers component of the URI does not have to be in the 
>>> percent-coded format as part of the ABNF of the headers component 
>>> defined in RFC3261:

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 03 Jan 2017 14:39:01 -0600

Do I read correctly that while Marianne's notes says the "=" "does not 
have" to be escaped, the reality is that is "not allowed" to be escaped? 
If so, the note probably needs an adjustment.

On 3 Jan 2017, at 12:29, Robert Sparks wrote:

> Eh - nevermind - Marianne's point is that escaping that particulear 
> "=" _isn't_ allowed by the ABNF (shown by what she quotes).
>
>> it's still allowed to encode it. I don't see how making the change 
>> you propose with the errata will help anyone?
>>
>> RjS
>>
>>
>>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 3 Jan 2017 14:46:36 -0600

That's how I read it, yes.

On 1/3/17 2:39 PM, Ben Campbell wrote:
> have" to be escaped, the reality is that is "not allowed" to be 
> escaped? If so, the note probably needs an adjustment.
>

---

From: <[email-masked]>
Date: Tue, 3 Jan 2017 21:21:53 +0000

Hi Robert,

FYI, we have experienced an equipment that rejects a REFER because of parsing issues caused by percent-coded characters not identified as ABNF elements for the header. 
Indeed, this only an example in RFC3515 and that's why I put the "editorial" category for the Errata.

>From RFC3261 :
Characters other than those in the "reserved" set (see RFC 2396 [5]) are equivalent to their ""%" HEX HEX" encoding.
-> which is not the case of the reserved character "=" 

BR,
Marianne
-----Message d'origine-----
De : Robert Sparks [mailto:[email-masked]] 
Envoyé : mardi 3 janvier 2017 19:30
À : Ben Campbell; SIPCORE
Cc : [email-masked]; [email-masked]; [email-masked]; [email-masked]; MOHALI Marianne IMT/OLN
Objet : Re: [Editorial Errata Reported] RFC3515 (4898)

So, this is an bug in an example, and the error doesn't affect the specification. This one should go into 'hold for document update'.

RjS

On 1/3/17 12:20 PM, Robert Sparks wrote:
>>> The following errata report has been submitted for RFC3515, "The 
>>> Session Initiation Protocol (SIP) Refer Method".
>>>
>>> rejected. When a decision is reached, the verifying party can log in 
>>> to change the status and edit the report, if necessary.
>>>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Robert Sparks <[email-masked]>
Date: Tue, 3 Jan 2017 15:23:58 -0600

> -> which is not the case of the reserved character "="
More specifically, the URI production rules you quote are more specific 
about what can be escaped than the rest of the ABNF are, and that 
particular "=" sign does not allow escaping where it is produced.

---

From: <[email-masked]>
Date: Tue, 3 Jan 2017 22:20:19 +0000

So sentence:
>The "=" between the header name (hname) and the value (hvalue) in the headers component of the URI does not have to be in the percent-coded format as part of the ABNF of the headers component defined in RFC3261:

should be modified to:
The "=" between the header name (hname) and the value (hvalue) in the headers component of the URI must not be in the percent-coded format as part of the ABNF of the headers component defined in RFC3261:

ok?

BR,
Marianne
-----Message d'origine-----
De : Robert Sparks [mailto:[email-masked]] 
Envoyé : mardi 3 janvier 2017 21:47
À : Ben Campbell
Cc : SIPCORE; [email-masked]; [email-masked]; [email-masked]; [email-masked]; MOHALI Marianne IMT/OLN
Objet : Re: [Editorial Errata Reported] RFC3515 (4898)

On 1/3/17 2:39 PM, Ben Campbell wrote:
>>>>> 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 can log 
>>>>> in to change the status and edit the report, if necessary.
>>>>>