Subject: [sipcore] Errata suggestion: RFC 7315 ABNF correction

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Sep 2015 11:08:36 +0000

Hi,

At the previous 3GPP CT1 meeting an issue with the ABNF in RFC 7315 was raised.

The ABNF says:

access-info            =                     cgi-3gpp / utran-cell-id-3gpp /
                                                          dsl-location / i-wlan-node-id /
                                                          ci-3gpp2 / eth-location /
                                                          ci-3gpp2-femto / fiber-location /
                                                          np / gstn-location /local-time-zone /
                                                          dvb-rcs2-node-id / extension-access-info
np                     =                             "network-provided"
extension-access-info  =         gen-value

All current access-info values, except for 'np', are according to generic-param, but the ABNF only allows gen-value for new values. We believe that new values should also be according to generic-param.

(From RFC 3261: generic-param  =  token [ EQUAL gen-value ])

OLD:

extension-access-info  =         gen-value

NEW:

extension-access-info  =         generic-param

My suggestion is to open an errata for this, and fix the ABNF.

Comments?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Sep 2015 12:09:51 -0400

What is proposed makes sense - it is in the spirit of most typical 
header syntax.

The only real concern I can see here is with backward compatibility. 
Because the revision allows syntax that was previously forbidden, an 
entity that hasn't been updated may reject a request containing such new 
syntax. Whether that is practical problem depends on deployment.

RFC7315 doesn't seem to say anything about how a request containing 
extension-access-info should be processed. Typically unknown stuff 
matching an extension point it to be ignored, but nothing is said about 
it in this draft.

Also, there is no mention of when and how extensions may be introduced. 
Lacking any other statement, I presume it would take an update/revision 
to this rfc to define a new access-info value. If so, that at least 
means there would be no backward compatibility concern until there is 
such a revision.

	Thanks,
	Paul

On 9/11/15 7:08 AM, Christer Holmberg wrote:
>                                                            ci-3gpp2 /
> eth-location /
> All current access-info values, except for ‘np’, are according to
> generic-param, but the ABNF only allows gen-value for new values. We
> believe that new values should also be according to generic-param.
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Sep 2015 20:01:56 +0000

Hi,

> What is proposed makes sense - it is in the spirit of most typical header syntax.
>
> Because the revision allows syntax that was previously forbidden, an entity that hasn't been updated may reject a
> request containing such new syntax. Whether that is practical problem depends on deployment.

I am pretty sure 3GPP is the only user of this header field, and 3GPP agreed to bring the suggested change to IETF.

> RFC7315 doesn't seem to say anything about how a request containing extension-access-info should be processed. Typically 
> unknown stuff matching an extension point it to be ignored, but nothing is said about it in this draft.
>
> Lacking any other statement, I presume it would take an update/revision to this rfc to define a new access-info value. If so, that 
> at least means there would be no backward compatibility concern until there is such a revision.

I think an errata would be enough. I really don't see a need for a new RFC in order to do this fix.

Also, 3GPP has already defined at least one new access-info value, using the generic-param syntax, so at some point I guess we'll need to discuss what it takes to get that registered. But, I think that is a separate issue.

Regards,

Christer

On 9/11/15 7:08 AM, Christer Holmberg wrote:
> All current access-info values, except for 'np', are according to

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 12 Sep 2015 00:57:27 -0400

> I think an errata would be enough. I really don't see a need for a new RFC in order to do this fix.

I wasn't suggesting that the *errata* (erratum?) requires an RFC.
I was guessing that defining actual new access-info values would require 
an RFC. That at least would mean that existing implementations would 
have warning that they need to get ready to see the new syntax.

> Also, 3GPP has already defined at least one new access-info value, using the generic-param syntax, so at some point I guess we'll need to discuss what it takes to get that registered. But, I think…

It would have been nice for the document to define *some* mechanism for 
registering defined values, or otherwise ensuring that there won't be 
conflicting values. But I'm not especially bothered in this case, since 
this is pretty much a 3gpp-specific header.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 12 Sep 2015 17:59:30 +0000

Hi,

>>> entity that hasn't been updated may reject a request containing such new syntax. Whether that is practical problem depends on deployment.
>>
>>> extension-access-info should be processed. Typically unknown stuff matching an extension point it to be ignored, but nothing is said about it in this draft.
>>>
>>> Lacking any other statement, I presume it would take an 
>>> update/revision to this rfc to define a new access-info value. If so, that at least means there would be no backward compatibility concern until there is such a revision.
>>

Ok. Good :)

> I was guessing that defining actual new access-info values would require an RFC. That at least would mean that 
> existing implementations would have warning that they need to get ready to see the new syntax.
>
>> Also, 3GPP has already defined at least one new access-info value, using the generic-param syntax, so at 
>> some point I guess we'll need to discuss what it takes to get that registered. But, I think that is a separate issue.
>
> It would have been nice for the document to define *some* mechanism for registering defined values, or 
> otherwise ensuring that there won't be conflicting values. But I'm not especially bothered in this case, since this is pretty much a 3gpp-specific header.

At some point the question will come up regarding how/if the new values shall be registered, and whether an RFC will be required (I believe 3GPP currently only has one new value).

But, for now, are you ok to fix the ABNF as suggested?

Regards,

Christer

>>                                                             ci-3gpp2 
>> / eth-location /

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 12 Sep 2015 16:12:39 -0400

Yes.