Subject: [Sipping] [Fwd: I-D Action:draft-york-sipping-p-charge-info-00.txt]

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Feb 2008 09:24:51 +0200

Hi Dan,

are you aware of the work done on advice of charge by TISPAN/3GPP?
http://www.3gpp.org/ftp/Specs/html-info/24447.htm

Have you looked at the work some of us did with
http://merlot.tools.ietf.org/html/draft-jennings-sipping-pay-06
It also includes an charge info XML schema.

Ciao
Hannes

-------- Original Message --------
Subject: 	I-D Action:draft-york-sipping-p-charge-info-00.txt
Date: 	Mon, 18 Feb 2008 14:00:02 -0800 (PST)
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : P-Charge-Info - A Private Header (P-Header) Extension to the Session Initiation Protocol (SIP)
	Author(s)       : D. York
	Filename        : draft-york-sipping-p-charge-info-00.txt
	Pages           : 6
	Date            : 2008-02-18

This document describes 'P-Charge-Info', a private Session Initiation
Protocol (SIP) header (P-header) used by a number of equipment
vendors and carriers to convey simple billing information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-york-sipping-p-charge-info-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-york-sipping-p-charge-info-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-york-sipping-p-charge-info-00.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 19 Feb 2008 14:32:16 +0200

We also did some work in RFC 3455 in the format of the P-Charging-Vector 
header field.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

---

From: Dan York <[email-masked]>
Date: Tue, 19 Feb 2008 10:00:52 -0500

Miguel,

Yes, as soon as I saw that we were considering using P-Charge-Info I  
went looking around to see if it had been registered with IANA (it  
wasn't) and looking at what *was* registered with IANA.  I did see  
RFC 3455 (and indeed reference it in my draft) and looked at P- 
Charging-Vector. However, P-Charging-Vector is more complicated than  
we need.  Undoubtedly P-Charging-Vector works well within the larger  
context of 3GPP, but all we want to do is provide a single billing  
identifier to the upstream proxies.

What I am really aiming to do with this draft is register an already  
existing practice of using the P-Charge-Info P-Header with IANA, as  
is required under RFC 3427 (section 4.1).  Sonus Networks is using  
this in their switches and has mentioned it to carriers using their  
gear.  One of those carriers, who we work with, suggested it as a way  
to solve our billing issues.  We're now using it and it's working  
fine.  There are now other carriers with whom we are seeking to solve  
the same issue and we will probably wind up using the same  
solution.    We can obviously just continue to do this in the private  
SIP communication between ourselves and the carriers without pursuing  
IANA registration, but, being a "standards guy" I would like to "do  
the right thing" per RFC 3427 and document/register current usage.  I  
would also, frankly, like a document out there to which we can point  
when we talk to yet another carrier saying "here's one way of dealing  
with billing issues, is that applicable to your network?"

Hannes, thanks for the links. Again, though, all we are doing is  
passing along a simple billing identifier.

The -01 draft that I'll get in for Monday will include that  
information. (And someone from Sonus Networks has also agreed to co- 
author.)

Regards,
Dan

On Feb 19, 2008, at 7:32 AM, Miguel Garcia wrote:

> We also did some work in RFC 3455 in the format of the P-Charging- 
> Vector header field.
>
> /Miguel
>
> Hannes Tschofenig wrote:
>> Hi Dan,
>> 	Title           : P-Charge-Info - A Private Header (P-Header)  
>> Extension to the Session Initiation Protocol (SIP)
>> 	Author(s)       : D. York
>> [email-masked] with the word unsubscribe in the  
>> body of the message.
>> Internet-Drafts are also available by anonymous FTP. Login with  
>> the username "anonymous" and a password of your e-mail address.  
>> After logging in, type "cd internet-drafts" and then

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 20 Feb 2008 09:30:48 +0200

Hi Dan. See inline comments.

Dan York wrote:
> wasn't) and looking at what *was* registered with IANA.  I did see RFC 
> 3455 (and indeed reference it in my draft) and looked at 
> P-Charging-Vector. However, P-Charging-Vector is more complicated than 

It is hard to compare the P-Charge-Info with the P-Charging-Vector, 
because there is no formal definition or procedures associated to the 
P-Charge-Info in your draft.

However, I want to advocate the P-Charging-Vector for your purpose. The 
syntax of the P-Charging-Vector, specified in RFC 3455, is:

       P-Charging-Vector     = "P-Charging-Vector" HCOLON icid-value
                               *(SEMI charge-params)
       charge-params         = icid-gen-addr / orig-ioi /
                               term-ioi / generic-param
       icid-value            = "icid-value" EQUAL gen-value
       icid-gen-addr         = "icid-generated-at" EQUAL host
       orig-ioi              = "orig-ioi" EQUAL gen-value
       term-ioi              = "term-ioi" EQUAL gen-value

Of these, the only parameter that is mandatory is the icid-value, which 
merely is a token. The spec says:

    The P-Charging-Vector contains icid-value mandatory parameter.  The
    icid-value represents the IMS charging ID, and contains an identifier
    used for correlating charging records and events.

I think this is essentially what you want to do with the P-Charge-Info 
header.

> existing practice of using the P-Charge-Info P-Header with IANA, as is 
> required under RFC 3427 (section 4.1).  Sonus Networks is using this in 
> their switches and has mentioned it to carriers using their gear.  One 
> of those carriers, who we work with, suggested it as a way to solve our 
> billing issues.  We're now using it and it's working fine.  There are 
> now other carriers with whom we are seeking to solve the same issue and 
> we will probably wind up using the same solution.    We can obviously 
> just continue to do this in the private SIP communication between 
> ourselves and the carriers without pursuing IANA registration, but, 
> being a "standards guy" I would like to "do the right thing" per RFC 
> 3427 and document/register current usage.  I would also, frankly, like a 
> document out there to which we can point when we talk to yet another 
> carrier saying "here's one way of dealing with billing issues, is that 
> applicable to your network?"

I got it. So this is already implemented, deployed, but not documented. 
It is really a pity that people are doing this practice of specifying 
their own headers without asking for advice here in the IETF. I wonder 
what is the mess that can be created if one of these networks want to 
interoperate with IMS and exchange charging information.

/Miguel

> 
> Hannes, thanks for the links. Again, though, all we are doing is passing 
> along a simple billing identifier.   
> 
> The -01 draft that I'll get in for Monday will include that information. 
> (And someone from Sonus Networks has also agreed to co-author.)
> 
> Regards,
> Dan
> 
>

---

From: Dan York <[email-masked]>
Date: Wed, 20 Feb 2008 12:21:08 -0500

Miguel,

> because there is no formal definition or procedures associated to  
> the P-Charge-Info in your draft.

Oh, so you want me to provide *details*, do you?  The -00 draft I  
submitted on Monday was admittedly missing information.  Tolga  
Asveren from Sonus Networks and I have been swapping information and  
I'll be submitting a -01 in the next day or so with the appropriate  
information. Essentially the contents of the P-Charge-Info header is  
usually just a SIP URI conforming to 'addr-spec' in ABNF notation.

> I think this is essentially what you want to do with the P-Charge- 
> Info header.

I agree that the two are similar with the primary difference being  
the P-Charging-Vector will, as I read it, take *any* value while P- 
Charge-Info specifically takes a SIP URI as its value. P-Charge-Info  
has a somewhat simpler syntax in that it is just a SIP URI without  
any variable name (like "icid-value ="). For instance:

    P-Charge-Info: <sip:[email-masked]>

whereas P-Charging-Vector would be something like this if I read  
RFC3455 correctly:

   P-Charging-Vector: icid-value=[token]

where [token] appears to be a general number.

> I got it. So this is already implemented, deployed, but not  

Yes.  It turns out that Sonus Network equipment has been supporting  
this P-header for something like 2-3 years in customer deployments.   
So it is implemented, deployed but has not been formally registered  
with IANA.  (Hence this draft to start that process.)

> It is really a pity that people are doing this practice of  
> specifying their own headers without asking for advice here in the  
> IETF.

I don't know what interaction there was or was not with the IETF when  
this header was first developed (and neither does Tolga as its use  
predates his involvement with the company).  I do agree, though, that  
we do need people to look at what else is out there prior to creating  
their own headers. (And for all I know the people developing P-Charge- 
Info may have looked at P-Charging-Vector and decided that it didn't  
fit because they wanted to explicitly pass a SIP URI.)

> I wonder what is the mess that can be created if one of these  
> networks want to interoperate with IMS and exchange charging  
> information.

Yes, that obviously will be a factor.  Regardless, these networks are  
out there and being deployed today.  Part of the goal of this current  
exercise, in my opinion, is to document the current usage of P-Charge- 
Info so that someone else doesn't create yet another SIP P-Header to  
pass charging information.

Thanks for the comments - the new draft will be posted soon,
Dan

---

From: Dan York <[email-masked]>
Date: Thu, 21 Feb 2008 13:24:43 -0500

Miguel,

I have now posted the updated -01 version of this document which is  
also now co-authored by Tolga Asveren from Sonus Networks:

   http://www.ietf.org/internet-drafts/draft-york-sipping-p-charge- 
info-01.txt

Hopefully that will both explain the P-Charge-Info P-header more  
clearly and also explain the difference between P-Charge-Info and the  
P-Charging-Vector P-Header created by the 3GPP and documented in RFC  
3455.

What's not really clear to me, though, is what exactly I do next with  
this document.  Section 4.1 of RFC 3427 ( http://tools.ietf.org/ 
rfcmarkup?doc=rfc3427 ) indicates that a "designated expert" must  
review the document but the process is not clear to me how that all  
works.

Ultimately the goal is to register P-Charge-Info with IANA so that it  
appears on the SIP Parameters list at http://www.iana.org/assignments/ 
sip-parameters so that perhaps we can prevent other people from  
creating yet more P-headers that do the same thing (by finding out  
that there are now a couple available to them). Per RFC 3427 it would  
seem that we need to bring this Internet-Draft through to an  
Informational RFC.  For someone new to the process, though, RFC 3427  
is just a wee bit light on how that all is supposed to happen.

Regards,
Dan

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 21 Feb 2008 22:27:11 +0100

Hi Dan,
 
A few comments on the draft.

Q1. In chapter 1, you mention the Remote-Party-ID header. As far as I know, that never became standardized (correct me if I'm wrong), so should it really be listed? If listed, maybe it should be clarified that it is not a standardized header.

Q2. In chapter 1, where you describe the difference compared to the P-Charging-Vector header, you say the following:
 
"It also allows for the use of any general value as the billing identifier whereas P-Charge-Info, as noted below, specifically requires a SIP URI as the content.
 
generic-param means that you can extend the header, and define new header parameters - including one that carries a SIP URI value. It does not mean that you simply send whatever you want.
 
Also, as Miguel said earlier, there is only one mandatory parameter (icid-value) in P-Charging-Vector. I think some more detailed text with the problems you see in that would be useful.

Q3. In chapter 3.3 you say the following:
 
"The content of the P-Charge-Info header is typically simply a SIP URI used as a billing indicator."
 
Later, below the first example, you then say:
 
"Any other applicable SIP URI could be used."
 
Do you mean to say "Any other applicable URI..."?

Regards,
 
Christer

________________________________

From: [email-masked] on behalf of Dan York
Sent: Thu 21/02/2008 19:24
To: Miguel Garcia
Cc: SIPPING LIST
Subject: [Sipping] Draft -01 now posted - Re: [Fwd: I-DAction:draft-york-sipping-p-charge-info-00.txt]

Miguel,

I have now posted the updated -01 version of this document which is also now co-authored by Tolga Asveren from Sonus Networks:

  http://www.ietf.org/internet-drafts/draft-york-sipping-p-charge-info-01.txt

Hopefully that will both explain the P-Charge-Info P-header more clearly and also explain the difference between P-Charge-Info and the P-Charging-Vector P-Header created by the 3GPP and documented in RFC 3455.

What's not really clear to me, though, is what exactly I do next with this document.  Section 4.1 of RFC 3427 ( http://tools.ietf.org/rfcmarkup?doc=rfc3427 ) indicates that a "designated expert" must review the document but the process is not clear to me how that all works.

Ultimately the goal is to register P-Charge-Info with IANA so that it appears on the SIP Parameters list at http://www.iana.org/assignments/sip-parameters so that perhaps we can prevent other people from creating yet more P-headers that do the same thing (by finding out that there are now a couple available to them). Per RFC 3427 it would seem that we need to bring this Internet-Draft through to an Informational RFC.  For someone new to the process, though, RFC 3427 is just a wee bit light on how that all is supposed to happen.

Regards,
Dan
-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com <http://www.voxeo.com/> 
Blogs: http://blogs.voxeo.com <http://blogs.voxeo.com/>   http://www.disruptivetelephony.com <http://www.disruptivetelephony.com/> 

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com <http://evolution.voxeo.com/>

---

From: Dan York <[email-masked]>
Date: Thu, 21 Feb 2008 21:38:11 -0500

Christer,

Many thanks for the feedback.

On Feb 21, 2008, at 4:27 PM, Christer Holmberg wrote:
>
> Q1. In chapter 1, you mention the Remote-Party-ID header. As far as  
> I know, that never became standardized (correct me if I'm wrong),  
> so should it really be listed? If listed, maybe it should be  
> clarified that it is not a standardized header.

DY> Good question.  From what I can gather from reading the archives,  
Remote-Party-ID was last defined in draft-ietf-sip-privacy ( http:// 
tools.ietf.org/rfcmarkup?draft=draft-ietf-sip-privacy-04.txt ) which  
expired back in 2002.  I also gather that it was replaced by P- 
Asserted-Identity from RFC 3325 ( http://tools.ietf.org/rfcmarkup? 
doc=rfc3325 ).

DY> So yes, you are correct, Remote-Party-ID was NOT standardized and  
would appear to be deprecated.

DY> However, Remote-Party-ID does seem to have entered into common  
usage. A web search turns up numerous pages talking about how to  
configure Asterisk to support the header "because some service  
providers are requiring it".  It is also supported in Cisco IOS  
( http://cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ 
ftsipext.html ) and Cisco MGC ( http://www.cisco.com/en/US/docs/ 
voice_ip_comm/pgw/9/feature/module/9.5_2_/FMSIPrpd.html ). I didn't  
really look through other manufacturers to know the degree of support  
out there.

DY> Because of the existing usage, I would guess that I probably need  
to still list it, but yes, it should be noted as NOT a standard header.

> Q2. In chapter 1, where you describe the difference compared to the  
> P-Charging-Vector header, you say the following:
>
> "It also allows for the use of any general value as the billing  
> identifier whereas P-Charge-Info, as noted below, specifically  
> requires a SIP URI as the content.
>
> generic-param means that you can extend the header, and define new  
> header parameters - including one that carries a SIP URI value. It  
> does not mean that you simply send whatever you want.

DY> Thank you for the clarification.  I am still learning the world  
of ABNF. I thought I understand that but obviously I was wrong.

> Also, as Miguel said earlier, there is only one mandatory parameter  
> (icid-value) in P-Charging-Vector. I think some more detailed text  
> with the problems you see in that would be useful.

DY> As I mentioned to Miguel, I am trying to document the existing  
usage of P-Charge-Info out there and make that existing usage easy to  
find (through the IANA SIP Parameters list) so that hopefully others  
looking for such headers can see P-Charging-Vector and P-Charge-Info  
and then not feel the need to go off and invent their own new P- 
header that does the same thing.

DY> I do not know precisely why the developers who implemented P- 
Charge-Info 3+ years ago did so. Perhaps they looked at P-Charging- 
Vector and decided for their parsing routines that they didn't want  
to have a "name=value" pair like "icid-value = <token>" but instead  
just simply wanted a SIP URI as the value of the field.  Perhaps they  
had some other reason.  Perhaps they didn't look at P-Charging-Vector  
at all.  I don't know as I had no involvement with it. The header  
also predates Tolga Asveren's involvement with Sonus Networks and so  
he does not know either.

DY> The reality is that the P-Charge-Info header has been out there  
in use for 2-3 years by multiple carriers and vendors and somehow I  
don't see it going away, nor do I expect the carriers for whom this  
is working well to be motivated to change it.   So to me it seems  
like we (IETF) have the choice to ignore it, with the possible  
outcome that someone else will decide that P-Charging-Vector doesn't  
work for them and go off and create yet another P-header that does  
the same thing as P-Charge-Info... or we register P-Charge-Info so  
that it, too, can be found and potentially used instead. (And of  
course someone can still decide that neither P-Charging-Vector or P- 
Charge-Info work for them and so they create another P-Header anyway  
but at least we'll have tried.)

> Do you mean to say "Any other applicable URI..."?

DY> Hmmm...  I *did* mean any other *SIP* URI as that is what the  
implementations all support.  In ABNF I am specifying this as "addr- 
spec" but does that then refer to any generic URI? How would I  
specify only a SIP URI?

Regards,
Dan

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 22 Feb 2008 08:13:10 +0100

Hi Dan,
 
Comments inline.

Q1. In chapter 1, you mention the Remote-Party-ID header. As far as I
know, that never became standardized (correct me if I'm wrong), so
should it really be listed? If listed, maybe it should be clarified that
it is not a standardized header.

DY> Good question.  From what I can gather from reading the archives,
Remote-Party-ID was last defined in draft-ietf-sip-privacy (
http://tools.ietf.org/rfcmarkup?draft=draft-ietf-sip-privacy-04.txt )
which expired back in 2002.  I also gather that it was replaced by
P-Asserted-Identity from RFC 3325 (
http://tools.ietf.org/rfcmarkup?doc=rfc3325 ).

DY> However, Remote-Party-ID does seem to have entered into common
usage. A web search turns up numerous pages talking about how to
configure Asterisk to support the header "because some service providers
are requiring it".  It is also supported in Cisco IOS (
http://cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftsipext.htm
l ) and Cisco MGC (
http://www.cisco.com/en/US/docs/voice_ip_comm/pgw/9/feature/module/9.5_2
_/FMSIPrpd.html ). I didn't really look through other manufacturers to
know the degree of support out there.

DY> Because of the existing usage, I would guess that I probably need to
still list it, but yes, it should be noted as NOT a standard header.
 
[CHH] There are many other non-standardized headers (e.g. based on
drafts which eventually expired, invented by the vendor himself, etc) in
use out there also, but as far as I know we normally don't refer to them
in our standards specs.

	Q2. In chapter 1, where you describe the difference compared to
the P-Charging-Vector header, you say the following:

	"It also allows for the use of any general value as the billing
identifier whereas P-Charge-Info, as noted below, specifically requires
a SIP URI as the content.

	generic-param means that you can extend the header, and define
new header parameters - including one that carries a SIP URI value. It
does not mean that you simply send whatever you want.

DY> Thank you for the clarification.  I am still learning the world of
ABNF. I thought I understand that but obviously I was wrong.
 
[CHH] We should also consider whether the ABNF of your header should
allow some kind of future extension (parameters etc). Currently it
doesn't. I think history has shown that sometimes people come up with
useful extensions for existing headers.

	Also, as Miguel said earlier, there is only one mandatory
parameter (icid-value) in P-Charging-Vector. I think some more detailed
text with the problems you see in that would be useful.

DY> As I mentioned to Miguel, I am trying to document the existing usage
of P-Charge-Info out there and make that existing usage easy to find
(through the IANA SIP Parameters list) so that hopefully others looking
for such headers can see P-Charging-Vector and P-Charge-Info and then
not feel the need to go off and invent their own new P-header that does
the same thing.

DY> I do not know precisely why the developers who implemented
P-Charge-Info 3+ years ago did so. Perhaps they looked at
P-Charging-Vector and decided for their parsing routines that they
didn't want to have a "name=value" pair like "icid-value = <token>" but
instead just simply wanted a SIP URI as the value of the field.  Perhaps
they had some other reason.  Perhaps they didn't look at
P-Charging-Vector at all.  I don't know as I had no involvement with it.
The header also predates Tolga Asveren's involvement with Sonus Networks
and so he does not know either.

DY> The reality is that the P-Charge-Info header has been out there in
use for 2-3 years by multiple carriers and vendors and somehow I don't
see it going away, nor do I expect the carriers for whom this is working
well to be motivated to change it.   So to me it seems like we (IETF)
have the choice to ignore it, with the possible outcome that someone
else will decide that P-Charging-Vector doesn't work for them and go off
and create yet another P-header that does the same thing as
P-Charge-Info... or we register P-Charge-Info so that it, too, can be
found and potentially used instead. (And of course someone can still
decide that neither P-Charging-Vector or P-Charge-Info work for them and
so they create another P-Header anyway but at least we'll have tried.)
 
[CHH] There are other non-standard headers our there, which have been
around for much longer, and be much more deployed. The Diversion header
is a good example, I think. Should we then standardize that, even if we
have History-Info??? I am not necessarily objecting to your header, I am
only saying that we should look whether there is an existing header that
we can use, and so far you haven't provided information why e.g.
P-Charging-Vector doesn't work. If there is noone at Sonus (or
elsewhere) who can give that information we need to try to figure out
ourselves :)

	"The content of the P-Charge-Info header is typically simply a
SIP URI used as a billing indicator."

DY> Hmmm...  I *did* mean any other *SIP* URI as that is what the
implementations all support.  In ABNF I am specifying this as
"addr-spec" but does that then refer to any generic URI? How would I
specify only a SIP URI?
 
[CHH] The ABNF in 3261 defines "SIP-URI", so I guess you could use that.
But, why do you want to restrict it to SIP-URIs?
 
Regards,
 
Christer

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 22 Feb 2008 10:21:52 +0200

Hi Dan:

First, I would support Christer in removing references to the 
Remote-Party-ID. This was the "project name" of a header used in 
PacketCable, if I recall correctly, that later was standardized as 
P-Asserted-Identity in RFC 3325. I don't think we need to promote 
"project name" headers.

IMHO there is something wrong with the syntax. Let me explain it.

The draft lists the following example of the header:

    P-Charge-Info: <sip:6835555555;npi=[email-masked]>

Notice that the 'npi' parameter is not a parameter of the value, but it 
is a parameter of the username in the SIP URI. If it were a parameter of 
the value, then the example would be:

    P-Charge-Info: <sip:[email-masked]>;npi=ISDN

So, essentially, you the 'npi' parameter is part of the 'userinfo' field 
in the SIP ABNF. Here is the relevant ABNF from RFC 3261:

SIP-URI          =  "sip:" [ userinfo ] hostport
                     uri-parameters [ headers ]
userinfo         =  ( user / telephone-subscriber ) [ ":" password ] "@"
user             =  1*( unreserved / escaped / user-unreserved )
user-unreserved  =  "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"

So, it is correct to include a semicolon and an equal sign in the 
userinfo field, but in my opinion it should be treated as an opaque 
string of 'user'.

However the draft explains the npi parameter as a separate parameter, 
and even goes to declare an enumeration of values. I think this does not 
fit much into the userinfo of RFC 3261.

And actualy, the current ABNF of the P-Charge-Info, does not much the 
example above, because what I said: the parameter should go after the 
URI, and actually even outside the angle brackets. So either the example 
or the ABNF is wrong.

      P-Charge-Info = "P-Charge-Info" HCOLON charge-param * (SEMI
              charge-param)
          charge-param = (addr-spec) * (SEMI charge-params)
          charge-params = (("npi" EQUAL npi-value))
          npi-value = ("ISDN" / "DATA" / "TELEX" / "PRIVATE" / "SPARE0" /
                   "SPARE1" / "SPARE2" / "SPARE3" / "SPARE4" / "SPARE5" /
                   "SPARE6" / "SPARE7" )

And yet one more thing. You use addr-spec, which is merely a SIP URI, 
without the angle brackets. You should be using name-addr which includes 
the brackets.

So, assuming the exmaple is correct, the ABNF you should be looking at is:

      P-Charge-Info = "P-Charge-Info" HCOLON addr-spec *(SEMI
              charge-param)
              ; addr-spec is specified in RFC 3261
          charge-params = ("npi" EQUAL npi-value) *(SEMI generic-param)
              ; generic-param is specired in RFC 3261
          npi-value = ("ISDN" / "DATA" / "TELEX" / "PRIVATE" / token)

BR,

     Miguel

Dan York wrote:
> Miguel,
> 
> I have now posted the updated -01 version of this document which is also 
> now co-authored by Tolga Asveren from Sonus Networks:
> 
> Hopefully that will both explain the P-Charge-Info P-header more clearly 
> and also explain the difference between P-Charge-Info and the 
> P-Charging-Vector P-Header created by the 3GPP and documented in RFC 3455.
> 
> this document.  Section 4.1 of RFC 3427 
> ( http://tools.ietf.org/rfcmarkup?doc=rfc3427 ) indicates that a 
> "designated expert" must review the document but the process is not 
> clear to me how that all works.
> 
> appears on the SIP Parameters list 
> at http://www.iana.org/assignments/sip-parameters so that perhaps we can 
> prevent other people from creating yet more P-headers that do the same 
> thing (by finding out that there are now a couple available to them). 
> Per RFC 3427 it would seem that we need to bring this Internet-Draft 
> through to an Informational RFC.  For someone new to the process, 
> though, RFC 3427 is just a wee bit light on how that all is supposed to 
> happen.
> 
> Regards,
> Dan
> -- 
> <mailto:[email-masked]>

---

From: Dan York <[email-masked]>
Date: Fri, 22 Feb 2008 08:27:51 -0500

Christer,

On Feb 22, 2008, at 2:13 AM, Christer Holmberg wrote:

> drafts which eventually expired, invented by the vendor himself,  
> etc) in use out there also, but as far as I know we normally don't  
> refer to them in our standards specs.

DY> Good point.  I'll remove the reference but include a note to the  
effect that some network use Remote-Party-ID but should NOT be doing  
so as it is deprecated in favor of PAI.

> [CHH] We should also consider whether the ABNF of your header  
> should allow some kind of future extension (parameters etc).  
> Currently it doesn't. I think history has shown that sometimes  
> people come up with useful extensions for existing headers.

DY> Good point.  I see Miguel has reformulated the ABNF in another  
message (thank you, Miguel!) and I'll take a look at that.

> [CHH] There are other non-standard headers our there, which have  
> been around for much longer, and be much more deployed. The  
> Diversion header is a good example, I think. Should we then  
> standardize that, even if we have History-Info??? I am not  
> necessarily objecting to your header, I am only saying that we  
> should look whether there is an existing header that we can use,  
> and so far you haven't provided information why e.g. P-Charging- 
> Vector doesn't work. If there is noone at Sonus (or elsewhere) who  
> can give that information we need to try to figure out ourselves :)

DY> *Excellent* questions - but I think the topic deserves a separate  
discussion thread, so I'll start that in a couple of hours.

> [CHH] The ABNF in 3261 defines "SIP-URI", so I guess you could use  
> that. But, why do you want to restrict it to SIP-URIs?

DY> The restriction to a SIP URL is purely because I am *documenting  
current usage* of a SIP P-Header per RFC 3427.  Keep in mind, I am  
**NOT** proposing a new SIP header for *standardization*.  All I am  
doing is seeking to register the current usage of a SIP P-Header with  
IANA as requested/required by section 4.1 of RFC 3427.

Thanks,
Dan

---

From: Dan York <[email-masked]>
Date: Fri, 22 Feb 2008 08:36:10 -0500

Miguel,

> P-Asserted-Identity in RFC 3325. I don't think we need to promote  

DY> Agreed.  As I just noted to Christer, I will remove Remote-Party- 
ID but will include a note explaining WHY and that Remote-Party-ID is  
deprecated.

> IMHO there is something wrong with the syntax. Let me explain it.

DY> Thank you for your analysis and review.  I'll think on that a bit  
and talk with Tolga about the parameter usage. (We (Voxeo) don't use  
the npi parameter but Tolga indicated that there were people who do,  
so I'll need to defer to him on precise usage and how we document it.)

> And yet one more thing. You use addr-spec, which is merely a SIP  
> URI, without the angle brackets. You should be using name-addr  
> which includes the brackets.

DY> Interesting. So 'name-addr' includes the angle brackets but 'addr- 
spec' does not.  Thanks.  (However, I do note that in your suggested  
rewrite of the ABNF you still used addr-spec. Is that correct?)

> So, assuming the exmaple is correct, the ABNF you should be looking  

DY> So I guess I owe you a beer in Philly, eh?

Many thanks for your critique and help,
Dan

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 22 Feb 2008 23:56:11 +0100

Hi,
 
I am not asking for a beer, but I think the ABNF can be improved a little even futher. 
 
Miguel proposed:
 
    P-Charge-Info = "P-Charge-Info" HCOLON addr-spec *(SEMI charge-param)

I don't think you need "*(SEMI" on two levels, so the ABNF could look like:
 
    P-Charge-Info = "P-Charge-Info" HCOLON addr-spec *(SEMI charge-param)
              ; addr-spec is specified in RFC 3261
    charge-param = (("npi" EQUAL npi-value) / generic-param)
              ; generic-param is specired in RFC 3261
    npi-value = ("ISDN" / "DATA" / "TELEX" / "PRIVATE" / token)

Regards,
 
Christer

From: [email-masked] on behalf of Dan York
Sent: Fri 22/02/2008 14:36
To: Miguel Garcia
Cc: SIPPING LIST; Christer Holmberg
Subject: Re: [Sipping] Draft -01 now posted - Re: [Fwd: I-DAction:draft-york-sipping-p-charge-info-00.txt]

Miguel, 

	First, I would support Christer in removing references to the Remote-Party-ID. This was the "project name" of a header used in PacketCable, if I recall correctly, that later was standardized as P-Asserted-Identity in RFC 3325. I don't think we need to promote "project name" headers.

DY> Agreed.  As I just noted to Christer, I will remove Remote-Party-ID but will include a note explaining WHY and that Remote-Party-ID is deprecated.

DY> Thank you for your analysis and review.  I'll think on that a bit and talk with Tolga about the parameter usage. (We (Voxeo) don't use the npi parameter but Tolga indicated that there were people who do, so I'll need to defer to him on precise usage and how we document it.)

	And yet one more thing. You use addr-spec, which is merely a SIP URI, without the angle brackets. You should be using name-addr which includes the brackets.

DY> Interesting. So 'name-addr' includes the angle brackets but 'addr-spec' does not.  Thanks.  (However, I do note that in your suggested rewrite of the ABNF you still used addr-spec. Is that correct?)

---

From: Miguel Garcia <[email-masked]>
Date: Sat, 23 Feb 2008 10:10:05 +0200

Hi Dan:

Inline comments

Dan York wrote:
> and talk with Tolga about the parameter usage. (We (Voxeo) don't use the 
> npi parameter but Tolga indicated that there were people who do, so I'll 
> need to defer to him on precise usage and how we document it.)

I think we are about to open another discussion, which is: assume 
someone defines a new header, which breaks SIP in a few aspects: it 
clashes with existing work, it breaks the ABNF, and perhaps other 
aspects. Then they come to the IETF saying: here is our header, we need 
to register it because it is already deployed. It is broken, unneeded, 
but deployed. How do we need to handle these cases?

If we document and register this case, then we are automatically 
legitimating the practice, beside, we are documenting something that 
breaks SIP (lack of expert review). If we change the spec to something 
that is according to SIP, then we don't have the excuse of "existing 
implementations", and then we should consider why this new header needs 
to exist when there are others that do the same job.

I think this should be the main point of discussion of your draft.

>> without the angle brackets. You should be using name-addr which 
>> includes the brackets.
> 
> DY> Interesting. So 'name-addr' includes the angle brackets but 
> 'addr-spec' does not.  Thanks.  (However, I do note that in your 
> suggested rewrite of the ABNF you still used addr-spec. Is that correct?)

Oh, that is an oversight, because I based the new ABNF on the existing 
one. So, it should say name-addr.

See you in Philly, where I guess we would have time for further discussions.

/Miguel

---

From: Miguel Garcia <[email-masked]>
Date: Sat, 23 Feb 2008 11:02:20 +0200

I agree with Christer, with
s/addr-spec/name-addr

/Miguel

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 23 Feb 2008 22:13:15 -0500

> I think this should be the main point of discussion of your draft.

I agree with Miguel here.

Note that we are having extensive discussions currently on already 
deployed usages of INFO. They are not going to be rubber stamped because 
they are deployed.

> See you in Philly, where I guess we would have time for further discussions.

To be consistent with "most" headers that carry URLs, it probably ought 
to be:

	(name-addr / addr-spec)

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 23 Feb 2008 22:18:07 -0500

I agree with Miguel and Christer, except

s:addr-spec:(name-addr / addr-spec)

But the agreement extends only to the specifics of the ABNF. I am not 
convinced that this header should be standardized at all.

	Paul

---

From: <[email-masked]>
Date: Mon, 25 Feb 2008 11:00:56 +0200

>Note that we are having extensive discussions currently on 
>already deployed usages of INFO. They are not going to be 
>rubber stamped because they are deployed.

This is a somewhat interesting aspect. 

Ideally, we would like to have people to do early implementations. That
typically takes a long time already. 

BUT: When someone raises the argument of "I have an implementation of
this draft." (in the hope that other people are impressed and like the
document more because of this reason) then the typical response is "What
does that show? I can get everything running in my lab. Deployment is
important." This is obviously true.

Now, when you come back and you have the deployment then people say
something like the above. 

Summary: Whatever you do it is wrong!

Ciao
Hannes

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 25 Feb 2008 11:40:44 +0100

The precise list of checks from RFC 3427 is as follows:

   1.  A designated expert (as defined in RFC 2434 [4]) MUST review the
       proposal for applicability to SIP and conformance to these
       guidelines.  The Expert Reviewer will send email to the Transport
       Area Directors on this determination.  The expert reviewer can
       cite one or more of the guidelines that haven't been followed in
       his/her opinion.

   2.  The proposed extension MUST NOT define SIP option tags, response
       codes, or methods.

   3.  The function of the proposed header MUST NOT overlap with current
       or planned chartered extensions.

   4.  The proposed header MUST be of a purely informational nature, and
       MUST NOT significantly change the behavior of SIP entities which
       support it.  Headers which merely provide additional information
       pertinent to a request or a response are acceptable.  If the
       headers redefine or contradict normative behavior defined in
       standards track SIP specifications, that is what is meant by
       significantly different behavior.

   5.  The proposed header MUST NOT undermine SIP security in any sense.
       The Internet Draft proposing the new header MUST address security
       issues in detail as if it were a Standards Track document.  Note
       that, if the intended application scenario makes certain
       assumptions regarding security, the security considerations only
       need to meet the intended application scenario rather than the
       general Internet case.  In any case, security issues need to be
       discussed for arbitrary usage scenarios (including the general
       Internet case).

   6.  The proposed header MUST be clearly documented in an (Individual
       or Working Group) Informational RFC, and registered with IANA.

   7.  An applicability statement in the Informational RFC MUST clearly
       document the useful scope of the proposal, and explain its
       limitations and why it is not suitable for the general use of SIP
       in the Internet. 

Note that the existing work overlap is only with WG chartered items,
therefore I do not see this as precluding an overlap between two
P-headers.

I believe your other comments, e.g. ABNF, are valid considerations that
must be dealt with.

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Miguel Garcia
> Sent: Saturday, February 23, 2008 8:10 AM
> To: Dan York
> Cc: SIPPING LIST; Christer Holmberg (JO/LMF)
> Subject: Re: [Sipping] Draft -01 now posted - Re: [Fwd: 
> I-DAction:draft-york-sipping-p-charge-info-00.txt]
> 
> Hi Dan:
> 
> Inline comments
> 
> Dan York wrote:
> > Miguel,
> > 
> I think we are about to open another discussion, which is: 
> assume someone defines a new header, which breaks SIP in a 
> few aspects: it clashes with existing work, it breaks the 
> ABNF, and perhaps other aspects. Then they come to the IETF 
> saying: here is our header, we need to register it because it 
> is already deployed. It is broken, unneeded, but deployed. 
> How do we need to handle these cases?
> 
> If we document and register this case, then we are 
> automatically legitimating the practice, beside, we are 
> documenting something that breaks SIP (lack of expert 
> review). If we change the spec to something that is according 
> to SIP, then we don't have the excuse of "existing 
> implementations", and then we should consider why this new 
> header needs to exist when there are others that do the same job.
> 
> Oh, that is an oversight, because I based the new ABNF on the 
> existing one. So, it should say name-addr.
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 25 Feb 2008 11:46:07 +0100

And while I am mentioning the check lists, P-headers are a SIP
extension, and therefore do need to follow RFC 4485.

I have not checked to see if it does.

Regards

Keith 

> [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
> Sent: Monday, February 25, 2008 10:41 AM
> To: Miguel Garcia; Dan York
> Subject: Re: [Sipping] Draft -01 now posted - Re: 
> [Fwd:I-DAction:draft-york-sipping-p-charge-info-00.txt]
> 
> Note that the existing work overlap is only with WG chartered 
> items, therefore I do not see this as precluding an overlap 
> between two P-headers.
> 
> I believe your other comments, e.g. ABNF, are valid 
> considerations that must be dealt with.
> 
> Keith
> 
> > assume someone defines a new header, which breaks SIP in a few 
> > aspects: it clashes with existing work, it breaks the ABNF, and 
> > perhaps other aspects. Then they come to the IETF
> > saying: here is our header, we need to register it because it is 
> > already deployed. It is broken, unneeded, but deployed.
> > implementations", and then we should consider why this new header 
> > needs to exist when there are others that do the same job.
> > 
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> >

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 25 Feb 2008 13:20:43 -0500

Christer,

Sorry for the late reply. Some comments below.

Thanks,
Tolga

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Christer Holmberg
> Sent: Thursday, February 21, 2008 4:27 PM
> To: Dan York; Miguel Garcia
> Cc: SIPPING LIST
[Fwd:I-DAction:draft-
> york-sipping-p-charge-info-00.txt]
> 
> Hi Dan,
> 
should
> it really be listed? If listed, maybe it should be clarified that it
is
> not a standardized header.
> 
> 
> Q2. In chapter 1, where you describe the difference compared to the P-
> Charging-Vector header, you say the following:
> 
identifier
> whereas P-Charge-Info, as noted below, specifically requires a SIP URI
as
> the content.
header
> parameters - including one that carries a SIP URI value. It does not
mean
> that you simply send whatever you want.
> 
(icid-
> value) in P-Charging-Vector. I think some more detailed text with the
> problems you see in that would be useful.
[TOLGA] Regarding why P-Charge-Info was seen as necessary rather than
reusing P-Charging-Vector, here is an attempt (it is hard to reconstruct
all the thinking process with valid/invalid arguments of the time this
decision has been taken, so just an attempt):

"P-Charging-Vector is mainly used to carry information for correlation
of multiple charging records generated for a single session. OTOH,
P-Charge-Info is used to convey information about the party to be billed
for a call. Furthermore, P-Charging-Vector has a mandatory icid-value
parameter, which is a globally unique value to identify the session, for
which the charging information is generated. Such an identifier is not
necessary, when carrying information about the user to be billed."

I guess in one of your messages, you implied that generic-param in
P-Charging-Vector could have been used for this purpose (?). Now, one
naive question: How to define semantics of such a proprietary parameter?
Again with an IETF document I would think. 

In general, I feel that the overall semantics of P-Charging-Vector and
P-Charge-Info are quite different to warrant a new header.
> Subject: [Sipping] Draft -01 now posted - Re: [Fwd:
I-DAction:draft-york-
> sipping-p-charge-info-00.txt]
> 
> 
> Miguel,
> 
also
> now co-authored by Tolga Asveren from Sonus Networks:
http://www.ietf.org/internet-drafts/draft-york-sipping-p-charge-info-
> 01.txt
clearly
> and also explain the difference between P-Charge-Info and the
P-Charging-
> Vector P-Header created by the 3GPP and documented in RFC 3455.
> 
this
> document.  Section 4.1 of RFC 3427 (
> http://tools.ietf.org/rfcmarkup?doc=rfc3427 ) indicates that a
"designated
> expert" must review the document but the process is not clear to me
how
> that all works.
> appears on the SIP Parameters list at
http://www.iana.org/assignments/sip-
> parameters so that perhaps we can prevent other people from creating
yet
> more P-headers that do the same thing (by finding out that there are
now a
> couple available to them). Per RFC 3427 it would seem that we need to
> bring this Internet-Draft through to an Informational RFC.  For
someone
> new to the process, though, RFC 3427 is just a wee bit light on how
that
> all is supposed to happen.
> 
> Regards,
> Dan
> --
> <http://www.voxeo.com/>
> Blogs: http://blogs.voxeo.com <http://blogs.voxeo.com/>
> http://www.disruptivetelephony.com
<http://www.disruptivetelephony.com/>
> Find out how at http://evolution.voxeo.com
<http://evolution.voxeo.com/>

---

From: Dan York <[email-masked]>
Date: Mon, 25 Feb 2008 13:37:00 -0500

Paul, Miguel, Christer,

Thanks for all of your comments and assistance with ABNF.  I have now  
submitted a -02 which should be popping out of the I-D queue as soon  
as I can get the verification email and approve it.

To this point of Paul's:

> I am not

I want to respond at greater length as Christer raised a similar  
point that I think bears discussing, but I will do that in a separate  
email thread.

Regards,
Dan

On Feb 23, 2008, at 10:18 PM, Paul Kyzivat wrote:

>>> Subject: Re: [Sipping] Draft -01 now posted - Re: [Fwd: I- 
>>> DAction:draft-york-sipping-p-charge-info-00.txt]
>>>
>>>
>>> Miguel,
>>>
>>> PacketCable, if I recall correctly, that later was standardized  
>>> as P-Asserted-Identity in RFC 3325. I don't think we need to  
>>> promote "project name" headers.
>>>
>>>
>>> DY> Agreed.  As I just noted to Christer, I will remove Remote- 
>>> Party-ID but will include a note explaining WHY and that Remote- 
>>> Party-ID is deprecated.
>>>
>>>
>>> DY> Thank you for your analysis and review.  I'll think on that a  
>>> bit and talk with Tolga about the parameter usage. (We (Voxeo)  
>>> don't use the npi parameter but Tolga indicated that there were  
>>> people who do, so I'll need to defer to him on precise usage and  
>>> how we document it.)
>>>
>>>

---

From: Dan York <[email-masked]>
Date: Mon, 25 Feb 2008 14:46:39 -0500

FYI, my draft -02 is now out at:

   http://tools.ietf.org/rfcmarkup?doc=draft-york-sipping-p-charge-info

It hopefully captures the comments and also ABNF corrections included  
here on the list.

As to the larger question of registering SIP P-Headers, I will write  
more on that but today need to get ready for a flight to Orlando in  
the morning (where Voxeo's corp office is), so it will probably be  
tomorrow before I do that.

Thanks for all the critique,
Dan

On Feb 25, 2008, at 1:37 PM, Dan York wrote:

> Paul, Miguel, Christer,
>
> Thanks for all of your comments and assistance with ABNF.  I have  
> now submitted a -02 which should be popping out of the I-D queue as  
> soon as I can get the verification email and approve it.
>
> To this point of Paul's:
>
>> I am not
> point that I think bears discussing, but I will do that in a  
> separate email thread.
>
> Regards,
> Dan