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 dyork@xxxxxxxxxxxxx <mailto:dyork@xxxxxxxxxxxxx>
Phone: +1-802-735-1624 skype:danyork
http://www.danyork.com/
http://twitter.com/danyork
--
Dan York dyork@xxxxxxxxxxxxx <mailto:dyork@xxxxxxxxxxxxx>
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.
--------------------------------------------------------
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
