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.
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.
