Re: [Sipping] draft-york-sipping-p-charge-info-12: ABNF

[Paul Kyzivat <[e-mail]>]

On 12/1/11 10:08 PM, Dan York wrote:
> Paul,
>
> Many thanks as always for your helpful comments. The question seems to
> be that we want to define ABNF that describes an example like this:
>
> P-Charge-Info: <sip:6835555555;npi=001;noa=3@10.10.7.21>

I have lost track, but I think there were prior proposals to incorporate 
the above parameters into the syntax of the tel URI. But AFAICT that was 
never done. (There were issues with it, raised by me among others.) (If 
they were valid in tel, then they would be valid in sip URIs too, since 
the sip uri can contain telephone-subscriber from the tel uri.)

IIUC, here you are trying to introduce these parameters into the user 
part of a sip uri, when used in P-Charge-Info, without extending them 
for other uses of the sip uri or tel uri. Is that right?

> The optional npi and noa parameters are parameters that are on the left
> side of the @ symbol in a SIP URI.
>
> In looking at the original ABNF we had in there, it does seem to me that
> it *was* incorrect, as it would have required a URI of something like
> one of these:
>
> P-Charge-Info: <sip:6835555555@10.10.7.21;npi=001;noa=3>
> P-Charge-Info: <sip:6835555555@10.10.7.21>;npi=001;noa=3

Yes, that is what it would have required. Whether that is correct or 
incorrect is an open question. But I guess it is contrary to your intent.

> I'm guessing the former... but it's irrelevant - the point is that
> either of these would be wrong. We need the ABNF to specify that THIS is
> the correct notation:
>
> P-Charge-Info: <sip:6835555555;npi=001;noa=3@10.10.7.21>
>
> So we really do want to specify somehow that "chargeparam" is part of
> the "userinfo" section of the SIP URI, and perhaps specifically the
> "user" section given these definitions:
>
>> RFC 3261:
>>
>> userinfo = ( user / telephone-subscriber ) [ ":" password ] "@"
>> user = 1*( unreserved / escaped / user-unreserved )
>>
>> RFC 2806:
>>
>> telephone-subscriber = global-phone-number / local-phone-number
>
> Any ABNF experts out there able to help me sort this out? The current
> formal definition is:

Technically the parameters you want are already *syntactically* valid, 
in two different ways:

They fit the definition of 'parameter' in tel (RFC 3966),

they are consistent within the definition of 'user' in 3261.

So in some sense you don't need to extend the syntax definitions at all. 
But that doesn't say anything about semantics. So at least you would 
need to define the semantics of these.

BUT...

There is now a registry of parameters for the TEL URI, defined by RFC 
5341. If you *don't* register these parameters there, then you run the 
risk that they might subsequently be registered by somebody else as tel 
uri parameter, with some different meaning.

So, I think you cheat if you don't define these as new tel uri 
parameters. But if you define them as tel uri parameters, then 
presumably they can be used anywhere a tel or sip uri can be used. 
Perhaps they could somehow be defined somehow to limit their use to 
certain contexts, but I don't know how you would go about that.

If these parameters are only to be meaningful in p-charge-info, then the 
right thing to do is define them as header field parameters, as you did 
have them once, even though they are then positioned differently than 
you were hoping for.

	Thanks,
	Paul

> ----
> The syntax of the P-Charge-Info header is described as follows:
>
> P-Charge-Info = "P-Charge-Info" HCOLON (name-addr / addr-spec)
> ; name-addr and addr-spec are specified in RFC 3261
> charge-param = npi-param / noa-param / generic-param
> npi-param = ";npi" EQUAL npi-value
> ; generic-param is specifed in RFC 3261
> npi-value = 3DIGIT
> noa-param = ";noa" EQUAL noa-value
> noa-value = gen-value
>
> The SIP URI is the billing indicator that is passed between the
> parties.
>
> charge-param is used as a userinfo parameter in P-Charge-Info.
> ----
>
> Thanks,
> Dan
>
> On Nov 29, 2011, at 8:59 PM, Paul Kyzivat wrote:
>
>> On 11/30/11 3:38 AM, Dan York wrote:
>>> Brett, (and replying from a slightly different address so that it will
>>> go to the SIPPING list)
>>>
>>> Thank you for the feedback and question. The ABNF in the draft has
>>> evolved over the past almost-4 years as various people more literate
>>> than I in ABNF have given us feedback and we've updated the draft.
>>>
>>> In the ABNF section, "chargeparam" is intended to represent that you
>>> could optionally have the "noa", "npi" parameters - or any other generic
>>> parameters found in RFC 3261(such as "user=phone")
>>
>> Including generic-param is a mechanism for making the syntax
>> compatible with future enhancements. But allowing it syntactically
>> doesn't specify how parameters that match generic-param are to be
>> processed if the are present on this header. Typically you would
>> specify in the draft that they should be ignored unless the behavior
>> is defined by some other specification.
>>
>>> Originally, the ABNF read:
>>>
>>> P-Charge-Info = "P-Charge-Info" HCOLON (name-addr / addr-spec)*
>>> (SEMI charge-param)
>>> ; name-addr and addr-spec are specified inRFC 3261
>>> <http://tools.ietf.org/html/rfc3261>
>>> charge-param = npi-param / noa-param / generic-param
>>>
>>>
>>> I thought that was fairly clear and made sense. However, I changed the
>>> ABNF in rev -10 in October 2010 to more simply:
>>>
>>> P-Charge-Info = "P-Charge-Info" HCOLON (name-addr / addr-spec)
>>> ; name-addr and addr-spec are specified inRFC 3261
>>> <http://tools.ietf.org/html/rfc3261>
>>> charge-param = npi-param / noa-param / generic-param
>>>
>>>
>>> after someone strongly made the case that the "* (SEMI charge-param)"
>>> was not required because it was a "userinfo parameter" to the
>>> name-addr/addr-spec element.
>>
>> That is something very different. What you have above are *header*
>> parameters for the P-Charge-Info header.
>>
>> It sounds like you are talking about TEL-URI parameters when the tel
>> uri has been converted to a sip URI. But if so, then you should be
>> defining an extension to the tel-uri syntax. And then you would need
>> to define the semantics relative to the tel-uri. (It isn't really
>> kosher to define the parameters on the tel-uri but then only define
>> their semantics relative to the P-Charge-Info header.)
>>
>> IMO its wrong to make this change. Rather you should go back to
>> defining these explicitly as header params for P-Charge-Info.
>>
>> Thanks,
>> Paul
>>
>>> Unfortunately, the email exchange about
>>> this seems to have NOT taken place on the mailing list but rather in a
>>> private email exchange - and I no longer have access to the archives of
>>> the email account where that occurred (I am no longer with Voxeo) - so I
>>> don't know who it was that argued for this change.
>>>
>>> I'm directly cc'ing John Haluska as he was involved in with a number of
>>> those exchanges and can perhaps clarify this.
>>>
>>> In reviewing section 19.1.1 of RFC 3261 (
>>> http://tools.ietf.org/html/rfc3261#section-19.1.1 ) and sections 19.1.2,
>>> 19.1.3, and 19.1.6 as well as the ABNF in section 25, I am guessing that
>>> the rationale was because the "charge-param" does fit into the "user"
>>> section of the URI.
>>>
>>> So that's a roundabout way of saying that it is part of "user", as I
>>> interpret the ABNF in RFC 3261.
>>>
>>> Do you have suggestions for how to make this clearer in the draft? Would
>>> the original ABNF be more useful to you? Should the sentence
>>> "charge-param is used as a userinfo parameter in P-Charge-Info" indicate
>>> that it is the "user" part of the "userinfo" field?
>>>
>>> Thanks,
>>> Dan
>>>
>>> P.S. After not receiving any feedback for many, many months I suddenly
>>> have received two email questions/comments about P-Charge-Info today. I
>>> don't know if this is as a result of the mention on a mailing list that
>>> Richard Shockey mentioned... but I was surprised.
>>>
>>> On Nov 29, 2011, at 1:35 PM, Brett Tate wrote:
>>>
>>>> Howdy,
>>>>
>>>> Draft-york-sipping-p-charge-info-12 includes the following ABNF
>>>> without explicitly indicating if the charge-param is part of user,
>>>> telephone-subscriber, or both. I'm not sure how to interpret the
>>>> charge-param statement since userinfo has no parameters (although user
>>>> and telephone-subscriber can have them).
>>>>
>>>> Is charge-param part of user, telephone-subscriber, or both? I
>>>> recommend updating section 7 to remove the ambiguity.
>>>>
>>>> Thanks,
>>>> Brett
>>>>
>>>>
>>>> ------
>>>>
>>>> Draft-york-sipping-p-charge-info-12:
>>>>
>>>> "The syntax of the P-Charge-Info header is described as follows:
>>>>
>>>> P-Charge-Info = "P-Charge-Info" HCOLON (name-addr / addr-spec)
>>>> ; name-addr and addr-spec are specified in RFC 3261
>>>> charge-param = npi-param / noa-param / generic-param
>>>> npi-param = ";npi" EQUAL npi-value
>>>> ; generic-param is specifed in RFC 3261
>>>> npi-value = gen-value
>>>> noa-param = ";noa" EQUAL noa-value
>>>> noa-value = gen-value
>>>>
>>>> The SIP URI contained in the name-addr/addr-spec is the billing
>>>> indicator that is passed between the parties.
>>>>
>>>> charge-param is used as a userinfo parameter in P-Charge-Info."
>>>>
>>>>
>>>> RFC 3261:
>>>>
>>>> userinfo = ( user / telephone-subscriber ) [ ":" password ] "@"
>>>> user = 1*( unreserved / escaped / user-unreserved )
>>>>
>>>> RFC 2806:
>>>>
>>>> telephone-subscriber = global-phone-number / local-phone-number
>>>>
>>>
>>> --
>>> Dan York [e-mail] <mailto:[e-mail]>
>>> <mailto:[e-mail]>
>>> Phone: [phone] skype:danyork
>>> http://www.danyork.com/
>>> http://twitter.com/danyork
>>>
>>>
>>>
>>> --
>>> Dan York [e-mail] <mailto:[e-mail]>
>>> <mailto:[e-mail]>
>>> http://www.danyork.com/ skype:danyork
>>> Phone: [phone]
>>> Twitter - http://twitter.com/danyork
>>> --------------------------------------------------------
>>> All comments and opinions are entirely my own and have no connection
>>> whatsoever to any employer, past or present. Indeed, by tomorrow even I
>>> might be disavowing these comments.
>>> --------------------------------------------------------
>>>
>>>
>>>
>>> _______________________________________________
>>> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
>>> This list is for NEW development of the application of SIP
>>> Use [e-mail]
>>> <mailto:[e-mail]> for questions on current sip
>>> Use [e-mail] <mailto:[e-mail]> for new developments of core SIP
>>
>> _______________________________________________
>> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use [e-mail]
>> <mailto:[e-mail]> for questions on current sip
>> Use [e-mail] <mailto:[e-mail]> for new developments of core SIP
>
> --
> Dan York [e-mail] <mailto:[e-mail]>
> http://www.danyork.com/ skype:danyork
> Phone: [phone]
> Twitter - http://twitter.com/danyork
> --------------------------------------------------------
> All comments and opinions are entirely my own and have no connection
> whatsoever to any employer, past or present. Indeed, by tomorrow even I
> might be disavowing these comments.
> --------------------------------------------------------
>