Re: I-D Action:draft-york-sipping-p-charge-info-10.txt

Paul,

Yes, this draft has been around for a long time.  I was going to submit it as part of the RFC 3427 process but it was then suggested that I wait because of the RFC 3427bis process that became RFC 5727.  So it was kind of stuck in limbo for a bit and now we'd like to move it forward.

Answers inline prefixed by "DY>":

On Oct 25, 2010, at 7:25 PM, Paul Kyzivat wrote:

> I guess this draft has been going on for a long time.
> I took a quick look at this version.

DY> Thank you. I've not received much feedback outside the folks who care about this header because they currently use it.

> 
> Because it is intended to document existing practice I won't take issue with the good and the bad of the proposed form.

DY> Thank you.  That *is* the intent... P-Charge-Info has now been in usage for probably 5 years and so this is intended to document that usage.
> 
> I do have some issue with the formal syntax and the accompanying formal semantics. There are two header parameters defined: npi and noa. I suppose those names have some mnemonic signficance, but it is nowhere described in the draft. They might as well be "foo" and "bar".

DY> Good point.  They come from the world of PSTN and should be spelled out here.
> 
> Similarly the value syntax for those is gen-value, which is more or less "anything". Appendix A lists values from ANSI T1.113 in relation to npi, but there is no normative statement that the values should/must conform to that, or what should happen if they do not. And there isn't even that kind of hint for noa.

DY> Good feedback.
> 
> If, as is hinted at in appendix A, the values for npi are to be 3 digit numbers (or numbers in some range), then it would be helpful to document the syntax that way.

DY> How do we specify digits in ABNF?  For NPI we want to restrict it to 3 digit numbers, but I was not clear on how to do that in ABNF and so I wound up doing "gen-value".
> 
> If the intent is that these values really can be "anything", which must be agreed to out of band by the parties using the header, then that should be stated.
> 
> Similarly there really is no documented significance to the URI in this header. There should be some statement about the intended purpose of this URI.

DY> The URI is the billing identifier that is being transmitted from one system to the other.   I thought this was explained in the use-cases in section 4, but when I look at sections 4.x I can see that I am not being explicit there about the info being inserted into the URI.

> BTW, we don't really have a sipping group any longer. I presume this is to be treated as an individual submission or AD-sponsored. I've replied to the sipping mailing list, but that won't get a lot of readers. It might be best to announce it on the dispatch list.

DY> Correct, I am assuming at this point it will be an individual submission.  I have kept the name intact purely because it did originate back in the SIPPING group in 2008 and at this point I want to finalize the draft and submit it for expert review.  Good suggestion to send it over to DISPATCH, though.

Thanks again for the feedback,
Dan

-- 
Dan York, Director of Conversations
Voxeo Corporation   http://www.voxeo.com  [email protected]
Phone: +1-407-455-5859    Skype: danyork  

Join the Voxeo conversation:
Blogs: http://blogs.voxeo.com
Twitter: http://twitter.com/voxeo  http://twitter.com/danyork
Facebook: http://www.facebook.com/voxeo

_______________________________________________
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