Re: draft-york-sipping-p-charge-info-12: ABNF
Dan York <[email protected]> Tue, 29 Nov 2011 14:38:02 -0500
| Newsgroups | gmane.ietf.sipping |
|---|---|
| Message-ID | <[email protected]> |
--===============3013277610003242151==
Content-Type: multipart/alternative; boundary="Apple-Mail=_F82C0C6A-D69F-4BD0-BC94-28B2FF769182"
--Apple-Mail=_F82C0C6A-D69F-4BD0-BC94-28B2FF769182
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
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=3Dphone")
Originally, the ABNF read:
P-Charge-Info =3D "P-Charge-Info" HCOLON (name-addr / =
addr-spec)*
(SEMI charge-param)
; name-addr and addr-spec are specified in RFC 3261
charge-param =3D 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 =3D "P-Charge-Info" HCOLON (name-addr / =
addr-spec)
; name-addr and addr-spec are specified in RFC 3261
charge-param =3D 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. 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.=20
On Nov 29, 2011, at 1:35 PM, Brett Tate wrote:
> Howdy,
>=20
> 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).
>=20
> Is charge-param part of user, telephone-subscriber, or both? I =
recommend updating section 7 to remove the ambiguity.
>=20
> Thanks,
> Brett
>=20
>=20
> ------
>=20
> Draft-york-sipping-p-charge-info-12:
>=20
> "The syntax of the P-Charge-Info header is described as follows:
>=20
> P-Charge-Info =3D "P-Charge-Info" HCOLON (name-addr / =
addr-spec)
> ; name-addr and addr-spec are specified in RFC 3261
> charge-param =3D npi-param / noa-param / generic-param
> npi-param =3D ";npi" EQUAL npi-value
> ; generic-param is specifed in RFC 3261
> npi-value =3D gen-value
> noa-param =3D ";noa" EQUAL noa-value
> noa-value =3D gen-value
>=20
> The SIP URI contained in the name-addr/addr-spec is the billing
> indicator that is passed between the parties.
>=20
> charge-param is used as a userinfo parameter in P-Charge-Info."
>=20
>=20
> RFC 3261:
>=20
> userinfo =3D ( user / telephone-subscriber ) [ ":" password ] "@"
> user =3D 1*( unreserved / escaped / user-unreserved )
>=20
> RFC 2806:
>=20
> telephone-subscriber =3D global-phone-number / local-phone-number
>=20
--=20
Dan York [email protected]
Phone: +1-802-735-1624 skype:danyork
http://www.danyork.com/ =20
http://twitter.com/danyork
--=20
Dan York [email protected]
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.
--------------------------------------------------------
--Apple-Mail=_F82C0C6A-D69F-4BD0-BC94-28B2FF769182
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div>Brett, (and replying from a slightly different address so that it =
will go to the SIPPING list)</div><div><br></div><div>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.</div><div><br></div><div>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=3Dphone")</div><div><br></div><div>Originally, the ABNF =
read:</div><div><br></div><div><div><pre class=3D"newpage" =
style=3D"font-size: 1em; margin-top: 0px; margin-bottom: 0px; =
page-break-before: always; color: rgb(0, 0, 0); font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: =
0px; text-transform: none; widows: 2; word-spacing: 0px; =
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "> =
P-Charge-Info =3D "P-Charge-Info" HCOLON (name-addr / addr-spec)*
(SEMI charge-param)
; name-addr and addr-spec are specified in <a =
href=3D"http://tools.ietf.org/html/rfc3261">RFC 3261</a>
charge-param =3D npi-param / noa-param / =
generic-param</pre><div><br></div></div></div><div>I thought that was =
fairly clear and made sense. However, I changed the ABNF in rev =
-10 in October 2010 to more simply:</div><div><br></div><div><pre =
class=3D"newpage" style=3D"font-size: 1em; margin-top: 0px; =
margin-bottom: 0px; page-break-before: always; color: rgb(0, 0, 0); =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
-webkit-auto; text-indent: 0px; text-transform: none; widows: 2; =
word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; "> P-Charge-Info =3D =
"P-Charge-Info" HCOLON (name-addr / addr-spec)
; name-addr and addr-spec are specified in <a =
href=3D"http://tools.ietf.org/html/rfc3261">RFC 3261</a>
charge-param =3D npi-param / noa-param / =
generic-param</pre><div><br></div></div><div>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.</div><div><br></div><div>I'm directly =
cc'ing John Haluska as he was involved in with a number of those =
exchanges and can perhaps clarify this.</div><div><br></div><div>In =
reviewing section 19.1.1 of RFC 3261 ( <a =
href=3D"http://tools.ietf.org/html/rfc3261#section-19.1.1">http://tools.ie=
tf.org/html/rfc3261#section-19.1.1</a> ) 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.</div><div><br></div><div>So that's a =
roundabout way of saying that it is part of "user", as I interpret the =
ABNF in RFC 3261.</div><div><br></div><div>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?</div><div><br></div><div>Thanks,</div><div>Dan</div><div><br></div>=
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. <div><br><div><div>On Nov 29, 2011, at 1:35 PM, Brett =
Tate wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>Howdy,<br><br>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).<br><br>Is charge-param part of user, telephone-subscriber, or =
both? I recommend updating section 7 to remove the =
ambiguity.<br><br>Thanks,<br>Brett<br><br><br>------<br><br>Draft-york-sip=
ping-p-charge-info-12:<br><br>"The syntax of the P-Charge-Info header is =
described as follows:<br><br> =
P-Charge-Info =3D =
"P-Charge-Info" HCOLON (name-addr / addr-spec)<br> =
&n=
bsp; ; name-addr and addr-spec are specified in RFC =
3261<br> =
ch=
arge-param =3D npi-param / noa-param / generic-param<br> =
np=
i-param =3D ";npi" EQUAL npi-value<br> =
&n=
bsp; ; generic-param is specifed in RFC 3261<br> =
np=
i-value =3D gen-value<br> =
no=
a-param =3D ";noa" EQUAL noa-value<br> =
no=
a-value =3D gen-value<br><br> The SIP URI contained in the =
name-addr/addr-spec is the billing<br> indicator that is =
passed between the parties.<br><br> charge-param is used as =
a userinfo parameter in P-Charge-Info."<br><br><br>RFC =
3261:<br><br>userinfo =3D ( user / telephone-subscriber ) [ ":" =
password ] "@"<br>user =3D 1*( unreserved =
/ escaped / user-unreserved )<br><br>RFC =
2806:<br><br>telephone-subscriber =3D global-phone-number / =
local-phone-number<br><br></div></blockquote></div><br><div =
apple-content-edited=3D"true">
<div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><div><div style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
">-- <br>Dan York <a =
href=3D"mailto:[email protected]">[email protected]</a></div><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Phone: =
+1-802-735-1624 <a =
href=3D"skype:danyork">skype:danyork</a><br><a =
href=3D"http://www.danyork.com/">http://www.danyork.com/</a> <b=
r><a =
href=3D"http://twitter.com/danyork">http://twitter.com/danyork</a></div></=
div></div></div>
</div>
<br></div><br><br><div apple-content-edited=3D"true">
<div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; ">-- <br>Dan York <a =
href=3D"mailto:[email protected]">[email protected]</a><br><a =
href=3D"http://www.danyork.com/">http://www.danyork.com/</a> &n=
bsp;<a href=3D"skype:danyork">skype:danyork</a><br>Phone: =
+1-802-735-1624<br>Twitter - <a =
href=3D"http://twitter.com/danyork">http://twitter.com/danyork</a></div><d=
iv style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; =
">--------------------------------------------------------</div></div><div=
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">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.</div><div style=3D"word-wrap: break-word; -webkit-nbsp-mode: =
space; -webkit-line-break: after-white-space; =
">--------------------------------------------------------</div></div>
</div>
<br></body></html>=
--Apple-Mail=_F82C0C6A-D69F-4BD0-BC94-28B2FF769182--
--===============3013277610003242151==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP
--===============3013277610003242151==--