Re: [dispatch] [sipcore] [Technical Errata Reported] RFC7315 (4474)

[Christer Holmberg <[e-mail]>]

Hi Cullen,

So, you are suggesting a SIPCORE draft that updates the ABNF?

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Cullen Jennings<mailto:[e-mail]>
Sent: ‎08/‎10/‎2015 23:17
To: Christer Holmberg<mailto:[e-mail]>
Cc: Ben Campbell<mailto:[e-mail]>; SIPCORE<mailto:[e-mail]>; DISPATCH list<mailto:[e-mail]>
Subject: Re: [dispatch] [sipcore] [Technical Errata Reported] RFC7315 (4474)


My 2 cents is still more appropriate to fix it with a draft that epodes  it not an Errata. Imagine an SBC or Firewall that is checking the SIP syntax using the ABNF. The odds of them seeing this change and implementing it much better with an RFC than an errata. Total work either way is minimal.


> On Sep 30, 2015, at 9:12 AM, Christer Holmberg <[e-mail]> wrote:
>
> Hi,
>
>> (+sipcore, dispatch)
>> (as individual)
>>
>> I just realized this discussion did not include the sipcore or dispatch lists, and probably should.
>>
>> Recap: Christer proposed an errata (4474) to RFC 7315. It proposes the following change:
>>
>>> Section 5.4 says:
>>>
>>> extension-access-info  = gen-value
>>>
>>> It should say:
>>>
>>> extension-access-info  = generic-param
>>
>> The generic-param construction allows the NAME = VALUE syntax as in the TS 24.229 extension Jean mentioned below.
>>
>> Keeping in mind the RFC in question was for 3GPP: Is anyone aware of implementations of 7315 that would be broken
>> by this? From Jean's example, it looks like 3GPP had already assumed generic-param.
>
> Correct.
>
> Also, comparing RFC 3455 and RFC 7315, *all but one* of the new access-info parameter values that were added in RFC 7315 follow the generic-param syntax.  So, it seems like we in IETF also assumed generic-param when we did RFC 7315 (and/or we were not concerned about parser issues), but nobody noticed the ABNF issue.
>
> And, as I said earlier, I am pretty sure this header is mostly (only?) used in 3GPP environments, and nobody in 3GPP objected to the change I am now suggesting. It was discussed in 3GPP, and the outcome was to file the errata.
>
> Finally, as Jean indicated, 3GPP has defined a new value, daylight-saving-time, which also uses the generic-param syntax.
>
> Regards,
>
> Christer
>
>
> On 23 Sep 2015, at 16:23, A. Jean Mahoney wrote:
>
>> FWIW - TS 24.229, which defines the values for access-info, considers
>> extension-access-info to be a generic-param, and not a gen-value as
>> specified RFC7315. 3GPP has defined one extension so far (7.2A.4):
>>
>>
>> daylight-saving-time = "daylight-saving-time" EQUAL quoted-string
>>
>> TS 124 229 - V12.9.0 - Digital cellular telecommunications system
>> (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; IP
>> multimedia call control protocol based on Session Initiation Protocol
>> (SIP) and Session Description Protocol (SDP); Stage 3 (3GPP TS 24.229
>> version 12.9.0 Release 12) The daylight-saving-time is an instance of
>> generic-param from the current extension-access-info component of the
>> P- Access-Network-Info header field defined in RFC
>> 7315 [52].
>>
>>
>> Jean
>>
>>
>>
>> On 9/23/15 3:47 PM, Cullen Jennings wrote:
>>> I can see that it might have been better if it had been done this way
>>> Christer is proposing but I don't see how you can change it now. This
>>> change would break existing parsers that checked this. That does not
>>> seem like an errata level thing to me.
>>>
>>>
>>>> On Sep 21, 2015, at 10:30 AM, Ben Campbell <[e-mail]> wrote:
>>>>
>>>> sipcore and dispatch chairs:
>>>>
>>>> Do you have any concerns about accepting Christer's errata? (I note
>>>> RFC 7315 was an orphaned sipping draft progressed as AD sponsored.)
>>>>
>>>> Ben.
>>>>
>>>> Forwarded message:
>>>>
>>>>> From: Christer Holmberg <[e-mail]>
>>>>> To: Ben Campbell <[e-mail]>
>>>>> Cc: [e-mail] <[e-mail]>
>>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474)
>>>>> Date: Mon, 21 Sep 2015 10:26:26 +0000
>>>>>
>>>>> Any news on this?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Christer
>>>>>
>>>>> From: sipcore [mailto:[e-mail]] On Behalf Of
>>>>> Christer Holmberg
>>>>> Sent: 14. syyskuuta 2015 23:24
>>>>> To: Ben Campbell
>>>>> Cc: [e-mail]
>>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474)
>>>>>
>>>>> Hi Ben,
>>>>>
>>>>> I am pretty sure generic-param was the original intention. The
>>>>> majority of all existing value follow the generic-param syntax, and
>>>>> I can't think of any reason why new values would not follow the
>>>>> same syntax. That is how it works for other header fields too.
>>>>>
>>>>> I think this is due to a mistake, where someone thought that
>>>>> extension-access-info  represents the actual parameter name, and
>>>>> therefor only a value (gen-value) is needed. But,
>>>>> extension-access-info represents the whole rule (name AND value),
>>>>> why generic-param is needed :)
>>>>>
>>>>> Regards,
>>>>>
>>>>> Christer
>>>>>
>>>>> Sent from my Windows Phone
>>>>> ________________________________
>>>>> From: Ben Campbell<mailto:[e-mail]>
>>>>> Sent: ‎14/‎09/‎2015 21:31
>>>>> To: Christer Holmberg<mailto:[e-mail]>
>>>>> Cc: [e-mail]<mailto:[e-mail]>
>>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474)
>>>>> Hi Christer,
>>>>>
>>>>> Is it your understanding that the use of generic-param was the
>>>>> actual intention at the time 7315 was published? Or was gen-value
>>>>> the original intention, but we now think that it should have been
>>>>> generic-param?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Ben.
>>>>>
>>>>> On 14 Sep 2015, at 6:22, Christer Holmberg wrote:
>>>>>
>>>>>> FYI,
>>>>>>
>>>>>> I've now submitted the errata.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Christer
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: RFC Errata System [mailto:[e-mail]]
>>>>>> Sent: 14. syyskuuta 2015 14:21
>>>>>> To: [e-mail]<mailto:[e-mail]>;
>>>>>> [e-mail]<mailto:[e-mail]>;
>>>>>> Christer Holmberg;
>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>> Cc: Christer Holmberg;
>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>> Subject: [Technical Errata Reported] RFC7315 (4474)
>>>>>>
>>>>>> The following errata report has been submitted for RFC7315,
>>>>>> "Private Header (P-Header) Extensions to the Session Initiation
>>>>>> Protocol
>>>>>> (SIP)
>>>>>> for the 3GPP".
>>>>>>
>>>>>> --------------------------------------
>>>>>> You may review the report below and at:
>>>>>> http://www.rfc-editor.org/errata_search.php?rfc=7315&eid=4474
>>>>>>
>>>>>> --------------------------------------
>>>>>> Type: Technical
>>>>>> Reported by: Christer Holmberg
>>>>>> <[e-mail]<mailto:christer.holmberg@ericsson.
>>>>>> com>>
>>>>>>
>>>>>> Section: 5.4
>>>>>>
>>>>>> Original Text
>>>>>> -------------
>>>>>> extension-access-info  = gen-value
>>>>>>
>>>>>> Corrected Text
>>>>>> --------------
>>>>>> extension-access-info  = generic-param
>>>>>>
>>>>>> Notes
>>>>>> -----
>>>>>> Most of the pre-defined access-info values are following the
>>>>>> generic-param syntax. New access-info values (extensions) should
>>>>>> also be allowed to follow the generic-param syntax, in order to
>>>>>> allow both for a name and value of the extension.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> --------------------------------------
>>>>>> RFC7315 (draft-drage-sipping-rfc3455bis-14)
>>>>>> --------------------------------------
>>>>>> Title               : Private Header (P-Header) Extensions to the
>>>>>> Session Initiation Protocol (SIP) for the 3GPP
>>>>>> Publication Date    : July 2014
>>>>>> Author(s)           : R. Jesske, K. Drage, C. Holmberg
>>>>>> Category            : INFORMATIONAL
>>>>>> Source              : IETF - NON WORKING GROUP
>>>>>> Area                : N/A
>>>>>> Stream              : IETF
>>>>>> Verifying Party     : IESG
>>>>>>
>>>>>> _______________________________________________
>>>>>> sipcore mailing list
>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>> _______________________________________________
>>>>> sipcore mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch