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

[<[e-mail]>]

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:[e-mail]] 
Envoyé : mardi 3 janvier 2017 19:30
À : Ben Campbell; SIPCORE
Cc : [e-mail]; [e-mail]; [e-mail]; [e-mail]; MOHALI Marianne IMT/OLN
Objet : Re: [Editorial Errata Reported] RFC3515 (4898)

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:
> 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:
>> 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 <[e-mail]>
>>>
>>> Section: 2.1
>>>
>>> Original Text
>>> -------------
>>> Refer-To: <sip:[e-mail]?Accept-Contact=sip:bobsdesk.
>>> biloxi.example.net&Call-ID%3D55432%40alicepc.atlanta.example.com>
>>>
>>> Corrected Text
>>> --------------
>>> Refer-To: <sip:[e-mail]?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
>


_________________________________________________________________________________________________________________________

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.