Yes I knew most of that, and normally I wouldn't have mentioned it - there's nothing wrong with defining a private header for private use in an info RFC, as far as I'm concerned. And I think RFC 5727 even lets you keep the "P-" portion if it's just documenting known usage or is grandfathered. But it's the "ATIS is looking at this" part that would make one think perhaps it should NOT be a vendor-specific private-use header. And that was the spirit in which I was responding to Richard's email, since he mentioned the FCC. What two consenting adults wants to do is up to them - what the government mandates of all is a bigger deal. ;) So anyway... to answer your question of how to get it moving faster, it depends on what you want it for - if you just want to document what's been done and not get any input from others, the fastest way is probably to bypass the IETF. You can just request it be published by the RFC Editor independently, outside of the IETF. The designated expert reviewer would hopefully pick up on errors. But I'm not actually sure this draft would qualify if it uses userinfo-params, because as far as I know they'd have to be registered in the Tel-URI param registry which requires a standards-track doc I think. :( On the other hand, if you want community feedback and are willing to take input/changes to the proposed header, then this discussion should probably move to DISPATCH since that's the new "sipping" list. -hadriel On Dec 4, 2011, at 11:24 PM, Dan York wrote: > Hadriel, > > Soooo... a little background... this P-Charge-Info draft began life in February *2008* as a simple attempt to register a SIP header with IANA per RFC 3427 and to document the then *current practice* where the P-Charge-Info header was being used by my employer at the time (Voxeo, who I recently left in September 2011) and then subsequently how it was being used by people using Sonus Networks equipment. (See http://tools.ietf.org/html/draft-york-sipping-p-charge-info-01 ) > > That was it... a simple attempt to document how the P-Charge-Info header had been used for several *years* inside *existing* private networks so that it could be registered with IANA per RFC 3427. > > We (Voxeo) wanted to register the usage so that when we indicated to carriers that we wanted to use P-Charge-Info to exchange billing info, we could point them to a published RFC that defined the header. The exchange would happen on the private connection between our SIP cloud and theirs, but we wanted easy documentation we could point to. > > We also didn't want further proliferation of even more private headers that we would need to use and so hoped that documenting one would limit the proliferation of more. > > Other people and companies subsequently indicated they wanted to use the header as a way to pass the ISUP Charge Number. Folks from Telcordia, Alcatel-Lucent and other companies have been helping (along with, of course, Sonus Networks). Spencer Dawkins has also become involved because ATIS is apparently looking to reference this header in one of their standards. > > Unfortunately, a couple things happened along the way. > > First, our timing was terrible. We got caught up by the RFC3427bis effort that was underway in 2008/9 and that became RFC 5727 in 2010 and changed the way SIP headers were registered. In the midst of that, I received guidance from several folks that we should wait for the completion of that work as the process of registering SIP headers would be "easier". Second, it turned out that we did need some clarifications on the passing of the ISUP Charge Number via the NPI and NOA parameters, neither of which I personally worked with, and so it required getting assistance from various parties. Third, I had some changes within my role at my employer that added some delays on my end. > > In the meantime, a good number of folks out there started to seriously use this document and this header and have been asking rather regularly for the past year or so about when this work will be completed so they can have a published document that they can reference. > > At this point, all I want to do is get this document moved along the path toward becoming an Informational RFC. > > I actually thought it was good to go until last week when these questions were raised about the ABNF. Not being an ABNF expert, I'm trying to come to closure on what I need to get into the draft so that it will be clear to implementors and will work for them. > >> I can't remember where Sonus encodes the noa/npi fields, but I believe Dialogic encodes them as header-params in a "P-Charge-Info" header, not userinfo-params. > > Given that my co-author, Tolga Asveren, is from Sonus and he has been the main source of info for the noa/npi parameters, I'm going to believe that Sonus encodes them as userinfo-params. Unfortunately, given the path this draft has taken, Dialogic could have encoded them as header-params based on earlier versions of this draft (up to -09) where they were shown as being header-params. This was corrected in version -10 in October 2010, but obviously anyone doing an implementation in between would have had the guidance to use header-params. > > So again, at this point, I'd really just like to get this draft moved along so that we can document the current usage (except, I guess, for Dialogic) within private networks. > > Any ideas on how to get it moving faster would be greatly appreciated. > > Thanks, > Dan > > P.S. As to the "P-Charge-Info" name and RFC 5727, I'll again note that this originated in 2008 with trying to document current usage and pre-dates RFC 5727 (by 2 years). We address that here: > > http://tools.ietf.org/html/draft-york-sipping-p-charge-info-12#section-3 > > On Dec 4, 2011, at 11:06 AM, Hadriel Kaplan wrote: > >> >> If the goal is to make it an interoperable header to be used outside of a private network, rather than to just document a private header used by a particular vendor, then I would suggest this discussion be moved to DISPATCH rather than this supposedly-dead SIPPING mailing list. >> >> Further, it would probably require changing the header name (per RFC 5727), and getting consensus on the syntax and semantics. It would hopefully NOT require a new mini-WG, but could be an individual submission handled by the AD or an independent submission to the RFC Editor. >> >> Lastly, I should note that this draft in its current form contradicts some actual deployed usage of this header - in particular, I can't remember where Sonus encodes the noa/npi fields, but I believe Dialogic encodes them as header-params in a "P-Charge-Info" header, not userinfo-params. IF two vendors use the same header name but in different ways, then I think it argues even more strongly to use a brand-new header name for this draft. (and don't use "Charge", because that's already used by yet another vendor) >> >> -hadriel >> >> >> >> On Nov 29, 2011, at 2:01 PM, Richard Shockey wrote: >> >>> 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' >>> >> >> _______________________________________________ >> 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 > > -- > Dan York 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
