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

From: Brett Tate <[email-masked]>
Date: Tue, 29 Nov 2011 10:35:17 -0800

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

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 29 Nov 2011 14:01:28 -0500

Well well isn't this fascinating.

I was just having a conversation with Dan about this today.

This draft now takes on increasing significance as it solves a nasty little
problem of billing in one way SIP traffic (Skype -  Google Voice etal) that
is vexing the FCC and the carriers as they try to deal with what is
legalistically called "phantom traffic".   It's the preference I'm told is
if no calling party number is available use a CIC or OCN code of sorts. In
two way it could state the preference for billing which is either The CPN or
'Charging Number' 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brett Tate
Sent: Tuesday, November 29, 2011 1:35 PM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [Sipping] draft-york-sipping-p-charge-info-12: ABNF

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

------

RFC 3261:

RFC 2806:

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Dan York <[email-masked]>
Date: Tue, 29 Nov 2011 14:38:02 -0500

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")

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 in RFC 3261
             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:

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

-- 
Dan York  [email-masked]
Phone: +1-802-735-1624  skype:danyork
http://www.danyork.com/  
http://twitter.com/danyork

-- 
Dan York  [email-masked]
http://www.danyork.com/   skype:danyork
Phone: +1-802-735-1624
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.
--------------------------------------------------------

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 Nov 2011 09:59:53 +0800

On 11/30/11 3:38 AM, Dan York wrote:
> 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.

>                   ; name-addr and addr-spec are specified inRFC 3261  <http://tools.ietf.org/html/rfc3261>
> I thought that was fairly clear and made sense. However, I changed the
> ABNF in rev -10 in October 2010 to more simply:
>
>                   ; name-addr and addr-spec are specified inRFC 3261  <http://tools.ietf.org/html/rfc3261>
> 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.
>
> 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.
>
>> Draft-york-sipping-p-charge-info-12 includes the following ABNF
>> without explicitly indicating if the charge-param is part of user,
>> 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
>>
>>
>> ------
>>
> Dan York [email-masked] <mailto:[email-masked]>
> Dan York [email-masked] <mailto:[email-masked]>
> 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.

---

From: "Haluska, John J" <[email-masked]>
Date: Wed, 30 Nov 2011 08:10:43 -0500

Dan,

I'll take a look and let you know - I'm out of MIPS at the moment.

Thanks for continuing with this even though you've moved on.

John

From: Dan York [mailto:[email-masked]]
Sent: Tuesday, November 29, 2011 2:38 PM
To: Brett Tate
Cc: Tolga Asveren; [email-masked]; Haluska, John J
Subject: Re: draft-york-sipping-p-charge-info-12: ABNF

                 (SEMI charge-param)

                 ; name-addr and addr-spec are specified in RFC 3261<http://tools.ietf.org/html/rfc3261>

                 ; name-addr and addr-spec are specified in RFC 3261<http://tools.ietf.org/html/rfc3261>

Thanks,
Dan

Howdy,

Thanks,
Brett

------

RFC 3261:

RFC 2806:

--
Dan York  [email-masked]<mailto:[email-masked]>
Phone: +1-802-735-1624  skype:danyork
http://www.danyork.com/
http://twitter.com/danyork

--
Dan York  [email-masked]<mailto:[email-masked]>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 30 Nov 2011 15:18:45 -0500

Brett,

The answer for your question is "both", at least that was the intention.

Thanks,

Tolga

From: Haluska, John J [mailto:[email-masked]] 
Sent: Wednesday, November 30, 2011 8:11 AM
To: Dan York; Brett Tate
Cc: Asveren, Tolga; [email-masked]
Subject: RE: draft-york-sipping-p-charge-info-12: ABNF

Dan,

 

John

Brett, (and replying from a slightly different address so that it will
go to the SIPPING list)

         P-Charge-Info = "P-Charge-Info" HCOLON (name-addr / addr-spec)*
                 (SEMI charge-param)
                 ; name-addr and addr-spec are specified in RFC 3261
<http://tools.ietf.org/html/rfc3261> 
             charge-param = npi-param / noa-param / generic-param

         P-Charge-Info = "P-Charge-Info" HCOLON (name-addr / addr-spec)
                 ; name-addr and addr-spec are specified in RFC 3261
<http://tools.ietf.org/html/rfc3261> 
             charge-param = npi-param / noa-param / generic-param

name-addr/addr-spec element.  Unfortunately, the email exchange about

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

Howdy,

Thanks,
Brett

------

RFC 3261:

RFC 2806:

---

From: Brett Tate <[email-masked]>
Date: Wed, 30 Nov 2011 12:41:03 -0800

> > could optionally have the "noa", "npi" parameters - or any other
> > generic parameters found in RFC 3261(such as "user=phone")
> 

If charge-param remains within userinfo, generic-param should likely be changed to a more limited extention parameter since UTF8-NONASCII is not allowed within SIP-URI and tel URI because of escaping limitations.  RFC 3986 provides a mechanism for escaping UTF8-NONASCII within newer URI schemes.

RFC 3261:

generic-param  =  token [ EQUAL gen-value ]

gen-value      =  token / host / quoted-string

quoted-string  =  SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE

qdtext     =  LWS / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII

---

From: "Haluska, John J" <[email-masked]>
Date: Wed, 30 Nov 2011 18:46:30 -0500

Dan,

I don't think that it was me who commented about the ABNF. I'm not an ABNF expert so I'm probably not qualified to make a concrete recommendation here. I do agree that it'd be helpful to explicitly point out that the charge-params belong on the left hand side of the "@" sign.

Thanks

John

                 (SEMI charge-param)

Thanks,
Dan

Howdy,

Thanks,
Brett

------

RFC 3261:

RFC 2806: