Re: [Sipping] draft-york-sipping-p-charge-info-12: ABNF

Brett Tate <brett@broadsoft.com> Thu, 01 December 2011 14:22 UTC

Return-Path: <brett@broadsoft.com>
X-Original-To: sipping@ietfa.amsl.com
Delivered-To: sipping@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78C611E82CC for <sipping@ietfa.amsl.com>; Thu, 1 Dec 2011 06:22:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nk-G0y8-a5fO for <sipping@ietfa.amsl.com>; Thu, 1 Dec 2011 06:22:31 -0800 (PST)
Received: from smtpout01.partnerhosted.com (smtpedge02.chinookhosting.com [173.225.22.202]) by ietfa.amsl.com (Postfix) with ESMTP id 70F5011E8236 for <sipping@ietf.org>; Thu, 1 Dec 2011 06:22:30 -0800 (PST)
Received: from casumhub01.citservers.local (172.16.98.57) by FW02.citservers.local (172.16.98.4) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 1 Dec 2011 06:24:48 -0800
Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Thu, 1 Dec 2011 06:24:47 -0800
From: Brett Tate <brett@broadsoft.com>
To: "Asveren, Tolga" <tasveren@sonusnet.com>, Dan York <dan-ietf@danyork.org>, "sipping@ietf.org" <sipping@ietf.org>
Date: Thu, 01 Dec 2011 06:22:21 -0800
Thread-Topic: draft-york-sipping-p-charge-info-12: ABNF
Thread-Index: Acyuzmvijplp2eLHR2+O2k5m6ncpfQAkuT7gAA7y/MAAIpvXgA==
Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C1267A4FE@EXMBXCLUS01.citservers.local>
References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C1267A0F5@EXMBXCLUS01.citservers.local> <E4BBC312-18FF-46AC-A076-7FC34A75DC47@danyork.org> <8B6A9EC265011E4CB70F99C64426E8C206CA69B3B2@rrc-dte-exmb2.dte.telcordia.com> <033458F56EC2A64E8D2D7B759FA3E7E7040C614C@sonusmail04.sonusnet.com>
In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E7040C614C@sonusmail04.sonusnet.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Sipping] draft-york-sipping-p-charge-info-12: ABNF
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Dec 2011 14:22:32 -0000

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