> > 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
