Re: draft-york-sipping-p-charge-info-12: ABNF
"Haluska, John J" <[email protected]> Wed, 30 Nov 2011 18:46:30 -0500
| Newsgroups | gmane.ietf.sipping |
|---|---|
| Message-ID | <8B6A9EC265011E4CB70F99C64426E8C206CA69B6A9@rrc-dte-exmb2.dte.telcordia.com> |
--===============2755551876579017847== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_8B6A9EC265011E4CB70F99C64426E8C206CA69B6A9rrcdteexmb2dt_" --_000_8B6A9EC265011E4CB70F99C64426E8C206CA69B6A9rrcdteexmb2dt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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-p= arams belong on the left hand side of the "@" sign. Thanks John From: Dan York [mailto:[email protected]] Sent: Tuesday, November 29, 2011 2:38 PM To: Brett Tate Cc: Tolga Asveren; [email protected]; Haluska, John J Subject: Re: draft-york-sipping-p-charge-info-12: ABNF Brett, (and replying from a slightly different address so that it will go t= o 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 ABN= F 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 paramete= rs 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<http:/= /tools.ietf.org/html/rfc3261> charge-param =3D npi-param / noa-param / generic-param I thought that was fairly clear and made sense. However, I changed the ABN= F 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<http:/= /tools.ietf.org/html/rfc3261> charge-param =3D npi-param / noa-param / generic-param after someone strongly made the case that the "* (SEMI charge-param)" was n= ot required because it was a "userinfo parameter" to the name-addr/addr-spe= c element. Unfortunately, the email exchange about this seems to have NOT = taken place on the mailing list but rather in a private email exchange - an= d I no longer have access to the archives of the email account where that o= ccurred (I am no longer with Voxeo) - so I don't know who it was that argue= d for this change. I'm directly cc'ing John Haluska as he was involved in with a number of tho= se exchanges and can perhaps clarify this. In reviewing section 19.1.1 of RFC 3261 ( http://tools.ietf.org/html/rfc326= 1#section-19.1.1 ) and sections 19.1.2, 19.1.3, and 19.1.6 as well as the A= BNF in section 25, I am guessing that the rationale was because the "charg= e-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 interp= ret the ABNF in RFC 3261. Do you have suggestions for how to make this clearer in the draft? Would t= he 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 k= now if this is as a result of the mention on a mailing list that Richard Sh= ockey 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 exp= licitly indicating if the charge-param is part of user, telephone-subscribe= r, or both. I'm not sure how to interpret the charge-param statement since= userinfo has no parameters (although user and telephone-subscriber can hav= e them). Is charge-param part of user, telephone-subscriber, or both? I recommend u= pdating 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 =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 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 =3D ( user / telephone-subscriber ) [ ":" password ] "@" user =3D 1*( unreserved / escaped / user-unreserved ) RFC 2806: telephone-subscriber =3D global-phone-number / local-phone-number -- Dan York [email protected]<mailto:[email protected]> Phone: +1-802-735-1624 skype:danyork http://www.danyork.com/ http://twitter.com/danyork -- 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 whatso= ever to any employer, past or present. Indeed, by tomorrow even I might be = disavowing these comments. -------------------------------------------------------- --_000_8B6A9EC265011E4CB70F99C64426E8C206CA69B6A9rrcdteexmb2dt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/= /schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche= mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi= crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat= s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf= ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c= om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa= ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web= partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20= 06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200= 6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli= deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal= Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:= st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta http-equi= v=3DContent-Type content=3D"text/html; charset=3Dus-ascii"><meta name=3DGen= erator content=3D"Microsoft Word 12 (filtered medium)"><style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New";} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:Consolas;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple style=3D'word-wrap: break-word;-webkit-nbsp-mode: space;-webkit= -line-break: after-white-space'><div class=3DWordSection1><p class=3DMsoNor= mal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";colo= r:#1F497D'>Dan,<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'fo= nt-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> = ;</o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font= -family:"Calibri","sans-serif";color:#1F497D'>I don’t think that it w= as 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 agre= e that it’d be helpful to explicitly point out that the charge-params= belong on the left hand side of the “@” sign. <o:p></o:p></spa= n></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Cal= ibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=3DMs= oNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";= color:#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal><span style= =3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Than= ks<o:p></o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0p= t;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span= ></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Cali= bri","sans-serif";color:#1F497D'>John<o:p></o:p></span></p><p class=3DMsoNo= rmal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";col= or:#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal><span style=3D= 'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&n= bsp;</o:p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;f= ont-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></= p><div><div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0= pt 0in 0in 0in'><p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;fon= t-family:"Tahoma","sans-serif"'>From:</span></b><span style=3D'font-size:10= .0pt;font-family:"Tahoma","sans-serif"'> Dan York [mailto:dan-ietf@danyork.= org] <br><b>Sent:</b> Tuesday, November 29, 2011 2:38 PM<br><b>To:</b> Bret= t Tate<br><b>Cc:</b> Tolga Asveren; [email protected]; Haluska, John J<br><b= >Subject:</b> Re: draft-york-sipping-p-charge-info-12: ABNF<o:p></o:p></spa= n></p></div></div><p class=3DMsoNormal><o:p> </o:p></p><div><p class= =3DMsoNormal>Brett, (and replying from a slightly different address so that= it will go to the SIPPING list)<o:p></o:p></p></div><div><p class=3DMsoNor= mal><o:p> </o:p></p></div><div><p class=3DMsoNormal>Thank you for the = feedback and question. The ABNF in the draft has evolved over the pas= t almost-4 years as various people more literate than I in ABNF have given = us feedback and we've updated the draft.<o:p></o:p></p></div><div><p class= =3DMsoNormal><o:p> </o:p></p></div><div><p class=3DMsoNormal>In the AB= NF section, "chargeparam" is intended to represent that you could= optionally have the "noa", "npi" parameters - or any o= ther generic parameters found in RFC 3261(such as "user=3Dphone")= <o:p></o:p></p></div><div><p class=3DMsoNormal><o:p> </o:p></p></div><= div><p class=3DMsoNormal>Originally, the ABNF read:<o:p></o:p></p></div><di= v><p class=3DMsoNormal><o:p> </o:p></p></div><div><div><pre style=3D'p= age-break-before:always;orphans: 2;text-align:-webkit-auto;widows: 2;-webki= t-text-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px'><= span style=3D'font-size:12.0pt;color:black'> &= nbsp; P-Charge-Info =3D "P-Charge-Info" HCOLON (name-= addr / addr-spec)*<o:p></o:p></span></pre><pre style=3D'page-break-before:a= lways'><span style=3D'font-size:12.0pt;color:black'>  = ; (= SEMI charge-param)<o:p></o:p></span></pre><pre style=3D'page-break-before:a= lways'><span style=3D'font-size:12.0pt;color:black'>  = ; ;= name-addr and addr-spec are specified in <a href=3D"http://tools.ietf.org/= html/rfc3261">RFC 3261</a><o:p></o:p></span></pre><pre style=3D'page-break-= before:always'><span style=3D'font-size:12.0pt;color:black'> &nb= sp; charge-param =3D = npi-param / noa-param / generic-param<o:p></o:p></span></pre><div><p class= =3DMsoNormal><o:p> </o:p></p></div></div></div><div><p class=3DMsoNorm= al>I thought that was fairly clear and made sense. However, I changed= the ABNF in rev -10 in October 2010 to more simply:<o:p></o:p></p></div><d= iv><p class=3DMsoNormal><o:p> </o:p></p></div><div><pre style=3D'page-= break-before:always;orphans: 2;text-align:-webkit-auto;widows: 2;-webkit-te= xt-size-adjust: auto;-webkit-text-stroke-width: 0px;word-spacing:0px'><span= style=3D'font-size:12.0pt;color:black'>  = ; P-Charge-Info =3D "P-Charge-Info" HCOLON (name-addr= / addr-spec)<o:p></o:p></span></pre><pre style=3D'page-break-before:always= '><span style=3D'font-size:12.0pt;color:black'> &nbs= p; ; name= -addr and addr-spec are specified in <a href=3D"http://tools.ietf.org/html/= rfc3261">RFC 3261</a><o:p></o:p></span></pre><pre style=3D'page-break-befor= e:always'><span style=3D'font-size:12.0pt;color:black'> &n= bsp; charge-param =3D npi-p= aram / noa-param / generic-param<o:p></o:p></span></pre><div><p class=3DMso= Normal><o:p> </o:p></p></div></div><div><p class=3DMsoNormal>after som= eone strongly made the case that the "* (SEMI charge-param)" was = not required because it was a "userinfo parameter" to the name-ad= dr/addr-spec element. Unfortunately, the email exchange about this se= ems to have NOT taken place on the mailing list but rather in a private ema= il exchange - and I no longer have access to the archives of the email acco= unt where that occurred (I am no longer with Voxeo) - so I don't know who i= t was that argued for this change.<o:p></o:p></p></div><div><p class=3DMsoN= ormal><o:p> </o:p></p></div><div><p class=3DMsoNormal>I'm directly cc'= ing John Haluska as he was involved in with a number of those exchanges and= can perhaps clarify this.<o:p></o:p></p></div><div><p class=3DMsoNormal><o= :p> </o:p></p></div><div><p class=3DMsoNormal>In reviewing section 19.= 1.1 of RFC 3261 ( <a href=3D"http://tools.ietf.org/html/rfc3261#sectio= n-19.1.1">http://tools.ietf.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, &nbs= p;I am guessing that the rationale was because the "charge-param"= does fit into the "user" section of the URI.<o:p></o:p></p></div= ><div><p class=3DMsoNormal><o:p> </o:p></p></div><div><p class=3DMsoNo= rmal>So that's a roundabout way of saying that it is part of "user&quo= t;, as I interpret the ABNF in RFC 3261.<o:p></o:p></p></div><div><p class= =3DMsoNormal><o:p> </o:p></p></div><div><p class=3DMsoNormal>Do you ha= ve suggestions for how to make this clearer in the draft? Would the o= riginal 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?<o:p></o:= p></p></div><div><p class=3DMsoNormal><o:p> </o:p></p></div><div><p cl= ass=3DMsoNormal>Thanks,<o:p></o:p></p></div><div><p class=3DMsoNormal>Dan<o= :p></o:p></p></div><div><p class=3DMsoNormal><o:p> </o:p></p></div><p = class=3DMsoNormal>P.S. After not receiving any feedback for many, many mont= hs I suddenly have received two email questions/comments about P-Charge-Inf= o today. I don't know if this is as a result of the mention on a mailing li= st that Richard Shockey mentioned... but I was surprised. <o:p></o:p><= /p><div><p class=3DMsoNormal><o:p> </o:p></p><div><div><p class=3DMsoN= ormal>On Nov 29, 2011, at 1:35 PM, Brett Tate wrote:<o:p></o:p></p></div><p= class=3DMsoNormal><br><br><o:p></o:p></p><div><p class=3DMsoNormal style= =3D'margin-bottom:12.0pt'>Howdy,<br><br>Draft-york-sipping-p-charge-info-12= includes the following ABNF without explicitly indicating if the charge-pa= ram is part of user, telephone-subscriber, or both. I'm not sure how = to interpret the charge-param statement since userinfo has no parameters (a= lthough user and telephone-subscriber can have them).<br><br>Is charge-para= m part of user, telephone-subscriber, or both? I recommend updating s= ection 7 to remove the ambiguity.<br><br>Thanks,<br>Brett<br><br><br>------= <br><br>Draft-york-sipping-p-charge-info-12:<br><br>"The syntax of the= P-Charge-Info header is described as follows:<br><br> &nb= sp; P-Charge-Info =3D "P-Charge-Info" HCOL= ON (name-addr / addr-spec)<br> &nb= sp; ; name-addr and addr-spe= c are specified in RFC 3261<br> &n= bsp; charge-param =3D npi-param / noa-param / generi= c-param<br> &nbs= p; npi-param =3D ";npi" EQUAL npi-value<br>  = ; &n= bsp;; generic-param is specifed in RFC 3261<br> &nbs= p; npi-value =3D gen-value<br>&nbs= p; noa-par= am =3D ";noa" EQUAL noa-value<br> &n= bsp; noa-value =3D gen-value<br><br>&nbs= p; The SIP URI contained in the name-addr/addr-spec is the billing<br>= indicator that is passed between the parties.<br><br> &nbs= p;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= <o:p></o:p></p></div></div><p class=3DMsoNormal><o:p> </o:p></p><div><= div><div><div><div><p class=3DMsoNormal>-- <br>Dan York <a href= =3D"mailto:[email protected]">[email protected]</a><o:p></o:p></p></div= ><div><p class=3DMsoNormal>Phone: +1-802-735-1624 <a href=3D"sky= pe:danyork">skype:danyork</a><br><a href=3D"http://www.danyork.com/">http:/= /www.danyork.com/</a> <br><a href=3D"http://twitter.com/danyork"= >http://twitter.com/danyork</a><o:p></o:p></p></div></div></div></div></div= ><p class=3DMsoNormal><o:p> </o:p></p></div><p class=3DMsoNormal style= =3D'margin-bottom:12.0pt'><o:p> </o:p></p><div><div><div><div><p class= =3DMsoNormal>-- <br>Dan York <a href=3D"mailto:[email protected]= om">[email protected]</a><br><a href=3D"http://www.danyork.com/">http://w= ww.danyork.com/</a> <a href=3D"skype:danyork">skype:danyor= k</a><br>Phone: +1-802-735-1624<br>Twitter - <a href=3D"http://twitter= .com/danyork">http://twitter.com/danyork</a><o:p></o:p></p></div><div><p cl= ass=3DMsoNormal>--------------------------------------------------------<o:= p></o:p></p></div></div><div><p class=3DMsoNormal>All comments and opinions= are entirely my own and have no connection whatsoever to any employer, pas= t or present. Indeed, by tomorrow even I might be disavowing these comments= .<o:p></o:p></p></div><div><p class=3DMsoNormal>---------------------------= -----------------------------<o:p></o:p></p></div></div></div><p class=3DMs= oNormal><o:p> </o:p></p></div></body></html>= --_000_8B6A9EC265011E4CB70F99C64426E8C206CA69B6A9rrcdteexmb2dt_-- --===============2755551876579017847== 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 --===============2755551876579017847==--