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

> Do you have a suggestion for how I would change this =

> to a more limited parameter within the ABNF? =A0

See http://www.ietf.org/mail-archive/web/sipping/current/msg17796.html for =
more information.

The following is a potential change for RFC 3966's Telephone-Subscriber.  T=
here is no need to add a new expandable parameter; Telephone-Subscriber alr=
eady has "parameter".  Any new ones should comply with "parameter"; this in=
cludes npi-param and noa-param.

   parameter            =3D ";" pname ["=3D" pvalue ]
   pname                =3D 1*( alphanum / "-" )
   pvalue               =3D 1*paramchar

       npi-param =3D ";npi" EQUAL npi-value
       npi-value =3D p-value
       noa-param =3D ";noa" EQUAL noa-value
       noa-value =3D p-value

The Telephone-Subscriber's par is expanded to include two new values: npi-p=
aram and noa-param.  The following is the resulting ABNF; I don't recall if=
 currently requires IANA registration:

par =3D parameter / extension / isdn-subaddress / npi-param / noa-param


The following is the recommended change for user; don't do it. :)  However =
if you need to do it and remain consistent with the "historic" nature of th=
e draft (i.e. not indicating user=3Dphone) or if need to avoid RFC 3966 non=
 compliance, you have a few options although not sure if any would actually=
 pass SIPCORE scrutiny.

1) You can indicate that user=3Dphone (instead of user=3Dip) is the default=
 for a P-Charge-Info SIP-URI.  Thus, it can be decoded as a Telephone-Subsc=
riber even though user=3Dphone was not added.  This is similar to RFC 3261 =
section 19.1.1 snippet.

         "The set of valid telephone-subscriber strings is a subset of
         valid user strings.  The user URI parameter exists to
         distinguish telephone numbers from user names that happen to
         look like telephone numbers.  If the user string contains a
         telephone number formatted as a telephone-subscriber, the user
         parameter value "phone" SHOULD be present.  Even without this
         parameter, recipients of SIP and SIPS URIs MAY interpret the
         pre-@ part as a telephone number if local restrictions on the
         name space for user name allow it."


2) You can indicate that user=3Dpci (instead of user=3Dip) is the default f=
or a P-Charge-Info SIP-URI.

userinfo         =3D  ( user / telephone-subscriber / p-ci) [ ":" password =
] "@"
p-ci =3D user *charge-param ; not sure if good enough
charge-param =3D npi-param / noa-param / parameter

user-param        =3D  "user=3D" ( "phone" / "ip" / "pci" / other-user)

3) You can indicate that the P-Charge-Info SIP-URI user can be parsed as p-=
ci when user=3Dip (i.e. the default).

userinfo         =3D  ( user / telephone-subscriber) [ ":" password ] "@"
p-ci =3D user *charge-param ; not sure if good enough
charge-param =3D npi-param / noa-param / 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