Re: draft-york-sipping-p-charge-info-12: ABNF

> > Is charge-param part of user, telephone-subscriber, or both?

> The answer for your question is "both", at least 
> that was the intention.

> So that's a roundabout way of saying that it is 
> part of "user", as I interpret the ABNF in RFC 3261.

If the draft's change was requested by Tolga, it sounds there is some disagreement concerning the intended change or interpretation.

> Do you have suggestions for how to make this clearer in the draft?

Yes; after reaching agreement upon where charge-param is supposed to be placed, be more explicit concerning how it fits into the existing ABNF of the specific URI (if not changing back to being a header parameter).

The following is snippet from section 7:
---
The syntax of the P-Charge-Info header is described as follows:

P-Charge-Info = "P-Charge-Info" HCOLON (name-addr / addr-spec)
           ; name-addr and addr-spec are specified in RFC 3261
       charge-param = npi-param / noa-param / generic-param
       npi-param = ";npi" EQUAL npi-value
           ; generic-param is specifed in RFC 3261
       npi-value = gen-value
       noa-param = ";noa" EQUAL noa-value
       noa-value = 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.
---

The draft indicates SIP URI and mentions userinfo; is the draft also enabling inclusion within tel URI and other URI schemes?  Note the following section 6.3 snippet: "The content of the P-Charge-Info header is typically simply a SIP URI used as a billing indicator."

If charge-param is allowed within telephone-subscriber (of SIP-URI or tel URI), it should explicitly mention RFC 3966 and indicate how it fits within a telephone-subscriber (i.e. charge-param can be used as a new par when included within telephone-subscriber).  And if doing so is only applicable within P-Charge-Info, charge-param should potentially instead be defined as a P-Charge-Info header parameter.

If charge-param is allowed within user of SIP-URI, it should explicitly indicate how it fits within user and how you know to decode the user portion's parameters without having added a new "user=" value or restricting which "user=" values are valid.  If you are relying upon P-Charge-Info instead of "user=" to imply this decode decision, charge-param should potentially instead be defined as a P-Charge-Info header parameter or limited to being a telephone-subscriber parameter.

_______________________________________________
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