Subject: [sipcore] FW: [Technical Errata Reported] RFC7315 (4474)

From: Christer Holmberg <[email-masked]>
Date: Mon, 14 Sep 2015 11:22:10 +0000

FYI,

I've now submitted the errata.

Regards,

Christer

-----Original Message-----
From: RFC Errata System [mailto:[email-masked]] 
Sent: 14. syyskuuta 2015 14:21
To: [email-masked]; [email-masked]; Christer Holmberg; [email-masked]
Cc: Christer Holmberg; [email-masked]
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 <[email-masked]>

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

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 14 Sep 2015 13:31:08 -0500

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:

> The following errata report has been submitted for RFC7315, "Private 
> Header (P-Header) Extensions to the Session Initiation Protocol (SIP) 
> for the 3GPP".
>
> 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.
>
> Title               : Private Header (P-Header) Extensions to the 
> Session Initiation Protocol (SIP) for the 3GPP
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 14 Sep 2015 20:23:32 +0000

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:[email-masked]>
Sent: ‎14/‎09/‎2015 21:31
To: Christer Holmberg<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474)

Hi Christer,

Thanks!

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Sep 2015 10:26:26 +0000

Any news on this?

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 14. syyskuuta 2015 23:24
To: Ben Campbell
Cc: [email-masked]
Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474)

Hi Ben,

Regards,

Christer

Thanks!

Ben.

On 14 Sep 2015, at 6:22, Christer Holmberg wrote:

> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Christer Holmberg;
> [email-masked]<mailto:[email-masked]>
> Cc: Christer Holmberg; [email-masked]<mailto:[email-masked]>
> Reported by: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
>
> Section: 5.4
>
> Original Text
> -------------
> [email-masked]<mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Sep 2015 07:41:42 +0000

PING.

From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 21. syyskuuta 2015 13:26
To: Ben Campbell
Cc: [email-masked]
Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474)

Any news on this?

Regards,

Christer

Hi Ben,

Regards,

Christer

Thanks!

Ben.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 30 Sep 2015 09:17:14 -0500

No one seems to have objected, so I will approve it.

Ben.

On 30 Sep 2015, at 2:41, Christer Holmberg wrote:

> 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
>
>> To: [email-masked]<mailto:[email-masked]>; 
>> [email-masked]<mailto:[email-masked]>; Christer 
>> Holmberg;
>> Cc: Christer Holmberg; 
>> [email-masked]<mailto:[email-masked]>
>> Reported by: Christer Holmberg 
>> <[email-masked]<mailto:[email-masked]>>
>>
>> Section: 5.4
>>
>> Original Text
>> -------------

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 30 Sep 2015 09:20:42 -0500

Oops, I spoke too soon. Cullen did object. I will comment in that 
thread.

Ben.

Christer, do you have any thoughts

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 30 Sep 2015 09:31:00 -0500

(+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:
> It should say:

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.

Ben.

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 <[email-masked]> 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 <[email-masked]>
>>>> To: Ben Campbell <[email-masked]>
>>>> Cc: [email-masked] <[email-masked]>
>>>> Date: Mon, 21 Sep 2015 10:26:26 +0000
>>>>
>>>> Any news on this?
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>> 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.
>>>>
>>>> extension-access-info represents the whole rule (name AND value), 
>>>> why generic-param is needed :)
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>> [email-masked]<mailto:[email-masked]>; 
>>>>> Christer Holmberg;

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Sep 2015 15:12:54 +0000

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:
>>
> 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:

> (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
>
>
>
>>>> 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.
>>>>
>>>>> The following errata report has been submitted for RFC7315, 
>>>>> "Private Header (P-Header) Extensions to the Session Initiation 
>>>>> Protocol
>>>>> (SIP)
>>>>> for the 3GPP".
>>>>>
>>>>> 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.
>>>>>

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch