Re: draft-york-sipping-p-charge-info-12: ABNF
Dan York <[email protected]> Thu, 1 Dec 2011 09:08:38 -0500
| Newsgroups | gmane.ietf.sipping |
|---|---|
| Message-ID | <[email protected]> |
--===============6399160606537917833== Content-Type: multipart/alternative; boundary="Apple-Mail=_9B9D3D66-DB0F-4459-9829-EB877FDBA392" --Apple-Mail=_9B9D3D66-DB0F-4459-9829-EB877FDBA392 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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=3D001;[email protected]> 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:[email protected];npi=3D001;noa=3D3> P-Charge-Info: <sip:[email protected]>;npi=3D001;noa=3D3 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=3D001;[email protected]> 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: >=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 Any ABNF experts out there able to help me sort this out? The current = formal definition is: ---- The syntax of the P-Charge-Info header is described as follows: 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 3DIGIT noa-param =3D ";noa" EQUAL noa-value noa-value =3D 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) >>=20 >> 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. >>=20 >> 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") >=20 > 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. >=20 >> Originally, the ABNF read: >>=20 >> P-Charge-Info =3D "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 =3D npi-param / noa-param / generic-param >>=20 >>=20 >> I thought that was fairly clear and made sense. However, I changed = the >> ABNF in rev -10 in October 2010 to more simply: >>=20 >> P-Charge-Info =3D "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 =3D npi-param / noa-param / generic-param >>=20 >>=20 >> 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. >=20 > That is something very different. What you have above are *header* = parameters for the P-Charge-Info header. >=20 > 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.) >=20 > IMO its wrong to make this change. Rather you should go back to = defining these explicitly as header params for P-Charge-Info. >=20 > Thanks, > Paul >=20 >> 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. >>=20 >> I'm directly cc'ing John Haluska as he was involved in with a number = of >> those exchanges and can perhaps clarify this. >>=20 >> 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. >>=20 >> So that's a roundabout way of saying that it is part of "user", as I >> interpret the ABNF in RFC 3261. >>=20 >> 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? >>=20 >> Thanks, >> Dan >>=20 >> 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: >>=20 >>> 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] <mailto:[email protected]> >> Phone: +1-802-735-1624 skype:danyork >> http://www.danyork.com/ >> http://twitter.com/danyork >>=20 >>=20 >>=20 >> -- >> Dan York [email protected] <mailto:[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. >> -------------------------------------------------------- >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 >=20 > _______________________________________________ > 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 --=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=_9B9D3D66-DB0F-4459-9829-EB877FDBA392 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; = ">Paul,<div><br></div><div>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:</div><div><br></div><div>P-Charge-Info: <<a = href=3D"sip:6835555555;npi=3D001;[email protected]">sip:6835555555;npi=3D= 001;[email protected]</a>></div><div><br></div><div>The optional npi = and noa parameters are parameters that are on the left side of the @ = symbol in a SIP URI.</div><div><br></div><div>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:</div><div><br></div><div>P-Charge-Info: <<a = href=3D"sip:[email protected]">sip:[email protected]</a>;npi=3D001= ;noa=3D3></div><div>P-Charge-Info: <<a = href=3D"sip:[email protected]">sip:[email protected]</a>>;npi=3D= 001;noa=3D3</div><div><br></div><div>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:</div><div><br></div><div><div>P-Charge-Info: <<a = href=3D"sip:6835555555;npi=3D001;[email protected]">sip:6835555555;npi=3D= 001;[email protected]</a>></div></div><div><br></div><div>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:</div><div><br></div><div><blockquote = type=3D"cite"><blockquote = type=3D"cite"></blockquote></blockquote><blockquote = type=3D"cite"></blockquote><blockquote type=3D"cite">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</blockquote></div><div><br></div><div>Any ABNF = experts out there able to help me sort this out? The current = formal definition = is:</div><div><br></div><div>----</div><div><div> The syntax = of the P-Charge-Info header is described as = follows:</div><div><br></div><div> = P-Charge-Info =3D "P-Charge-Info" HCOLON (name-addr / = addr-spec)</div><div> = ; name-addr and addr-spec are specified in RFC = 3261</div><div> = charge-param =3D npi-param / noa-param / = generic-param</div><div> = npi-param =3D ";npi" EQUAL npi-value</div><div> = ; generic-param is = specifed in RFC 3261</div><div> = npi-value =3D 3DIGIT</div><div> = noa-param =3D ";noa" EQUAL noa-value</div><div> = noa-value =3D = gen-value</div><div><br></div><div> The SIP URI is the = billing indicator that is passed between the</div><div> = parties.</div><div><br></div><div> charge-param is = used as a userinfo parameter in = P-Charge-Info.</div></div><div>----</div><div><br></div><div>Thanks,</div>= <div>Dan</div><div><br><div><div>On Nov 29, 2011, at 8:59 PM, Paul = Kyzivat wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div>On 11/30/11 3:38 AM, Dan York wrote:<br><blockquote = type=3D"cite">Brett, (and replying from a slightly different address so = that it will<br></blockquote><blockquote type=3D"cite">go to the SIPPING = list)<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">Thank you for = the feedback and question. The ABNF in the draft = has<br></blockquote><blockquote type=3D"cite">evolved over the past = almost-4 years as various people more = literate<br></blockquote><blockquote type=3D"cite">than I in ABNF have = given us feedback and we've updated the = draft.<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">In the ABNF = section, "chargeparam" is intended to represent that = you<br></blockquote><blockquote type=3D"cite">could optionally have the = "noa", "npi" parameters - or any other = generic<br></blockquote><blockquote type=3D"cite">parameters found in = RFC 3261(such as "user=3Dphone")<br></blockquote><br>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.<br><br><blockquote type=3D"cite">Originally, the ABNF = read:<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite"> = P-Charge-Info =3D = "P-Charge-Info" HCOLON (name-addr / = addr-spec)*<br></blockquote><blockquote type=3D"cite"> = &n= bsp; (SEMI = charge-param)<br></blockquote><blockquote type=3D"cite"> = &n= bsp; ; name-addr and addr-spec are specified = inRFC 3261 <<a = href=3D"http://tools.ietf.org/html/rfc3261">http://tools.ietf.org/html/rfc= 3261</a>><br></blockquote><blockquote type=3D"cite"> = &n= bsp;charge-param =3D npi-param / noa-param / = generic-param<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">I thought that = was fairly clear and made sense. However, I changed = the<br></blockquote><blockquote type=3D"cite">ABNF in rev -10 in October = 2010 to more simply:<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite"> = P-Charge-Info =3D = "P-Charge-Info" HCOLON (name-addr / = addr-spec)<br></blockquote><blockquote type=3D"cite"> = &n= bsp; ; name-addr and addr-spec are specified = inRFC 3261 <<a = href=3D"http://tools.ietf.org/html/rfc3261">http://tools.ietf.org/html/rfc= 3261</a>><br></blockquote><blockquote type=3D"cite"> = &n= bsp;charge-param =3D npi-param / noa-param / = generic-param<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">after someone = strongly made the case that the "* (SEMI = charge-param)"<br></blockquote><blockquote type=3D"cite">was not = required because it was a "userinfo parameter" to = the<br></blockquote><blockquote type=3D"cite">name-addr/addr-spec = element.<br></blockquote><br>That is something very different. What you = have above are *header* parameters for the P-Charge-Info = header.<br><br>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.)<br><br>IMO = its wrong to make this change. Rather you should go back to defining = these explicitly as header params for P-Charge-Info.<br><br><span = class=3D"Apple-tab-span" style=3D"white-space:pre"> = </span>Thanks,<br><span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span>Paul<br><br><blockquote = type=3D"cite">Unfortunately, the email exchange = about<br></blockquote><blockquote type=3D"cite">this seems to have NOT = taken place on the mailing list but rather in = a<br></blockquote><blockquote type=3D"cite">private email exchange - and = I no longer have access to the archives of<br></blockquote><blockquote = type=3D"cite">the email account where that occurred (I am no longer with = Voxeo) - so I<br></blockquote><blockquote type=3D"cite">don't know who = it was that argued for this change.<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">I'm directly = cc'ing John Haluska as he was involved in with a number = of<br></blockquote><blockquote type=3D"cite">those exchanges and can = perhaps clarify this.<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">In reviewing = section 19.1.1 of RFC 3261 (<br></blockquote><blockquote type=3D"cite"><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,<br></blockquote><blockquote type=3D"cite">19.1.3, and 19.1.6 as = well as the ABNF in section 25, I am guessing = that<br></blockquote><blockquote type=3D"cite">the rationale was because = the "charge-param" does fit into the "user"<br></blockquote><blockquote = type=3D"cite">section of the URI.<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">So that's a = roundabout way of saying that it is part of "user", as = I<br></blockquote><blockquote type=3D"cite">interpret the ABNF in RFC = 3261.<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">Do you have = suggestions for how to make this clearer in the draft? = Would<br></blockquote><blockquote type=3D"cite">the original ABNF be = more useful to you? Should the sentence<br></blockquote><blockquote = type=3D"cite">"charge-param is used as a userinfo parameter in = P-Charge-Info" indicate<br></blockquote><blockquote type=3D"cite">that = it is the "user" part of the "userinfo" = field?<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite">Thanks,<br></blockquote><blockquote = type=3D"cite">Dan<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">P.S. After not = receiving any feedback for many, many months I = suddenly<br></blockquote><blockquote type=3D"cite">have received two = email questions/comments about P-Charge-Info today. = I<br></blockquote><blockquote type=3D"cite">don't know if this is as a = result of the mention on a mailing list that<br></blockquote><blockquote = type=3D"cite">Richard Shockey mentioned... but I was = surprised.<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">On Nov 29, = 2011, at 1:35 PM, Brett Tate wrote:<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">Howdy,<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite">Draft-york-sipping-p-charge-info-12 includes the following = ABNF<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">without explicitly indicating if the charge-param is part = of user,<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">telephone-subscriber, or both. = I'm not sure how to interpret = the<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">charge-param statement since userinfo has no parameters = (although user<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">and telephone-subscriber can = have them).<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">Is charge-param part of user, = telephone-subscriber, or both? = I<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">recommend updating section 7 to remove the = ambiguity.<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite">Thanks,<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite">Brett<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite">------<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite">Draft-york-sipping-p-charge-info-12:<br></blockquote></block= quote><blockquote type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">"The syntax of the P-Charge-Info = header is described as follows:<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">P-Charge-Info =3D = "P-Charge-Info" HCOLON (name-addr / = addr-spec)<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">; name-addr and addr-spec are = specified in RFC 3261<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">charge-param =3D npi-param / = noa-param / generic-param<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">npi-param =3D ";npi" EQUAL = npi-value<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">; generic-param is specifed in = RFC 3261<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">npi-value =3D = gen-value<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">noa-param =3D ";noa" EQUAL = noa-value<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">noa-value =3D = gen-value<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">The SIP URI contained in the = name-addr/addr-spec is the = billing<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote= type=3D"cite">indicator that is passed between the = parties.<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">charge-param is used as a = userinfo parameter in = P-Charge-Info."<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">RFC = 3261:<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">userinfo =3D ( user / = telephone-subscriber ) [ ":" password ] = "@"<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite">user =3D 1*( unreserved / escaped / user-unreserved = )<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">RFC = 2806:<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote type=3D"cite">telephone-subscriber =3D = global-phone-number / = local-phone-number<br></blockquote></blockquote><blockquote = type=3D"cite"><blockquote = type=3D"cite"><br></blockquote></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite">--<br></blockquote><blockquote type=3D"cite">Dan York <a = href=3D"mailto:[email protected]">[email protected]</a> <<a = href=3D"mailto:[email protected]">mailto:[email protected]</a>><br>= </blockquote><blockquote type=3D"cite">Phone: +1-802-735-1624 <a = href=3D"skype:danyork">skype:danyork</a><br></blockquote><blockquote = type=3D"cite"><a = href=3D"http://www.danyork.com/">http://www.danyork.com/</a><br></blockquo= te><blockquote type=3D"cite"><a = href=3D"http://twitter.com/danyork">http://twitter.com/danyork</a><br></bl= ockquote><blockquote type=3D"cite"><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite">--<br></blockquote><blockquote type=3D"cite">Dan York <a = href=3D"mailto:[email protected]">[email protected]</a> <<a = href=3D"mailto:[email protected]">mailto:[email protected]</a>><br>= </blockquote><blockquote type=3D"cite"><a = href=3D"http://www.danyork.com/">http://www.danyork.com/</a> <a = href=3D"skype:danyork">skype:danyork</a><br></blockquote><blockquote = type=3D"cite">Phone: +1-802-735-1624<br></blockquote><blockquote = type=3D"cite">Twitter - <a = href=3D"http://twitter.com/danyork">http://twitter.com/danyork</a><br></bl= ockquote><blockquote = type=3D"cite">--------------------------------------------------------<br>= </blockquote><blockquote type=3D"cite">All comments and opinions are = entirely my own and have no connection<br></blockquote><blockquote = type=3D"cite">whatsoever to any employer, past or present. Indeed, by = tomorrow even I<br></blockquote><blockquote type=3D"cite">might be = disavowing these comments.<br></blockquote><blockquote = type=3D"cite">--------------------------------------------------------<br>= </blockquote><blockquote type=3D"cite"><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote = type=3D"cite">_______________________________________________<br></blockqu= ote><blockquote type=3D"cite">Sipping mailing list <a = href=3D"https://www.ietf.org/mailman/listinfo/sipping">https://www.ietf.or= g/mailman/listinfo/sipping</a><br></blockquote><blockquote = type=3D"cite">This list is for NEW development of the application of = SIP<br></blockquote><blockquote type=3D"cite">Use <a = href=3D"mailto:[email protected]">[email protected]= bia.edu</a> for questions on current sip<br></blockquote><blockquote = type=3D"cite">Use <a href=3D"mailto:[email protected]">[email protected]</a> for = new developments of core = SIP<br></blockquote><br>_______________________________________________<br= >Sipping mailing list <a = href=3D"https://www.ietf.org/mailman/listinfo/sipping">https://www.ietf.or= g/mailman/listinfo/sipping</a><br>This list is for NEW development of = the application of SIP<br>Use <a = href=3D"mailto:[email protected]">[email protected]= bia.edu</a> for questions on current sip<br>Use <a = href=3D"mailto:[email protected]">[email protected]</a> for new developments of = core SIP<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><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></div></body></html>= --Apple-Mail=_9B9D3D66-DB0F-4459-9829-EB877FDBA392-- --===============6399160606537917833== 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 --===============6399160606537917833==--