Subject: [Sipping] Comments on sipping-calling-party-category-01

From: "James M. Polk" <[email-masked]>
Date: Fri, 04 Nov 2005 13:40:16 -0600

This ID makes the claim that CPC in the PSTN carries important state 
information of the caller to enable it to do special things, to be 
continued into SIP signaling as if from the initiator of a dialog (if it 
actually started in the PSTN, and is coming through a GW) or to be used by 
a UA going to the PSTN, and defines a header to carry this information.

Where this is from and goes to the PSTN (over a bridged IP network), 
shouldn't RFC3372 define this already?

Where this is starting at a UA, shouldn't this be an assertion in a more 
secure, perhaps even signed, message body?

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

_______________________________________________
Sipping mailing list  https://www1.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: Rocky Wang <[email-masked]>
Date: Tue, 08 Nov 2005 08:55:18 -0800

Hi, James,
	The conception is derived from PSTN but it is still very useful
in SIP network. Let's suppose a call from a policeman station, it should
still have the rights and opportunity to override the called user's
barring service.
	To interworking with PSTN, I think it is better define a new
header to take this information, and also help for the supplementary
services' implementation in the SIP network.

Best Regards,
Rocky Wang

-----Original Message-----
Sender: [email-masked] [mailto:[email-masked]] On
behalf James M. Polk
Sent time: 2005年11月4日 11:40
Receiver: [email-masked]
Subject: [Sipping] Comments on sipping-calling-party-category-01

actually started in the PSTN, and is coming through a GW) or to be used
by 
a UA going to the PSTN, and defines a header to carry this information.

cheers,
James

                                 *******************

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Nov 2005 13:31:46 -0500

> still have the rights and opportunity to override the called user's

That is debatable. (*I* don't think the police have the right to
override my desire not to talk to them. And in practice they can't force
me to pick up the phone, so what is the point?)

In practice, this is just an example of the use of Roles. It is indeed
useful to have callers categorizable by Role, so that authorization may
be done by Role rather than simply by specific identity. I may choose to
authorize those with the role of "Family of pkyzivat" and not authorize
those with the Role "Police".

The PSTN has chosen to utilize a limited form of role based
authentication and authorization, with just a small number of roles. The
particular set of roles chosen seem somewhat arbitrary. Supporting
exactly that set in SIP is an accomodation to the PSTN. That isn't a bad
thing as long as it makes sense. But I think CPC suffers from having
some categories that aren't reasonably understood as roles.

> services' implementation in the SIP network.

I hate to define one header for this small set of roles, and then later
have to use an entirely different mechanism for roles in general. But it
appears a general notion of role will probably take quite awhile to
complete.

This sounds a bit like the dicotomy between the use of P-Asserted-ID and
SIP Identity. There, the P-Asserted-ID is a P- header precisely because
it was viewed as being applicable in a limited scope. Using a P-CPC
header is a similar approach.

The place where I have concerns is where the P-CPC may overlap with
other mechanisms already in SIP. I posted a note on this some time ago,
but there was no response to it. (Copy attached.)

Given the similarities, it strikes me that CPC perhaps would be better
as a parameter on the P-Asserted-ID header than as a new header, as in:

	P-Asserted-Identity: <tel:+12125551234>;cpc="police"

This seems consistent with the view that these are indeed properties of
the calling identity.

	Paul

> secure, perhaps even signed, message body?

Subject: Re: [Sipping] Comments on sipping-calling-party-category-01
From: Rocky Wang <[email-masked]>
To: "'James M. Polk'" <[email-masked]>, [email-masked]
Date: Tue, 08 Nov 2005 08:55:18 -0800
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>

Hi, James,

Best Regards,
Rocky Wang

-----Original Message-----

cheers,
James

                                 *******************

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 08 Nov 2005 16:15:03 -0600

I just think that this use-case *needs* to have an assertion included, and 
not be simply a header that can be added and subtracted (or modified).

"Roles" (or "Traits") is discussed in two IDs now:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-trait-authz-01.txt
http://www.ietf.org/internet-drafts/draft-tschofenig-sip-saml-04.txt

If you want a actually want a header to accomplish some form of 
differentiation, maybe this can be used:
http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-10.txt
although there isn't a use-case given in this doc to what you want. It 
could still be accomplished with the header, if one is used.

At 04:05 PM 11/8/2005 -0500, Anders Kristensen wrote:

>Paul Kyzivat wrote:
>Unfortunately, as defined in RFC 3325 PAID cannot have parameters.
>
>Anders

cheers,
James

                                 *******************

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 08 Nov 2005 18:21:03 -0500

James M. Polk wrote:
> I just think that this use-case *needs* to have an assertion included, 
> and not be simply a header that can be added and subtracted (or modified).
> 

IMO: P-Asserted-ID is to SIP-Identity as P-CPC is to SIP-SAML.

P-Asserted-ID and P-CPC both are based on a trusted, all knowing, 
network core. If you believe that P-Asserted-ID is an acceptable way to 
run your network then you will probably believe P-CPC is ok too. And the 
converse also applies.

	Paul

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 08 Nov 2005 18:16:59 -0600

>IMO: P-Asserted-ID is to SIP-Identity as P-CPC is to SIP-SAML.

fair, and I'm not necessarily backing SAML here, I am saying the assertion 
(which P-Asserted-ID has) is hte key that's needed here.  Is this new CPC 
ID stating the P-CPC header is an new assertion header from a trusted 
server known to all parties within a dialog?

>P-Asserted-ID and P-CPC both are based on a trusted, all knowing, network 
>core. If you believe that P-Asserted-ID is an acceptable way to run your 
>network then you will probably believe P-CPC is ok too. And the converse 
>also applies.
>
>         Paul
>

cheers,
James

                                 *******************

---

From: Rocky Wang <[email-masked]>
Date: Tue, 08 Nov 2005 16:28:59 -0800

Hi, Paul,
It is really debatable. One side is the subscriber's choice and another
side is related to some urgent issues, it is not easy to say which hold
a higher priority. But in urgent and security cases, service provider
must provide override functionalities to some special calling parties.

There are several choices:
1. Deliver this information by a parameter of the "From" header, but
sometimes the intermediary entity must have the opportunity to change
it. Till now, the Proxy server cannot do this.
2. Deliver it in the P-Asserted-Identity header. But the calling ID and
its category are two pieces of information. We should review it and then
decide which is better.
3. Convey it by a separated header. This is our choice.

As the decision in the SIP session in IETF, it is wonderful that the
From/To header can be changed in the dialog. If the two headers can be
changed by any entity during the initial transaction messages, including
the request and response messages, we can choose the first scheme also.
But you know, it is not decided now.

Rgds,
Rocky Wang

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, November 08, 2005 10:32 AM
To: Rocky Wang
Cc: 'James M. Polk'; [email-masked]
Subject: Re: [Sipping] Comments on sipping-calling-party-category-01

	Paul

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 08 Nov 2005 16:05:20 -0500

Anders

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 10 Nov 2005 21:28:36 +0100

> Unfortunately, as defined in RFC 3325 PAID cannot have parameters.

In that case, you could do
P-Asserted-Identity: <tel:+12125551234;cpc="police">
instead

As it is a property of the calling entity (like 'lr' is a property of the 
entity performing the routing)

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Nov 2005 21:59:13 -0500

inline

Jeroen van Bemmel wrote:
> As it is a property of the calling entity (like 'lr' is a property of 
> the entity performing the routing)

This approach presents a number of problems:

- it *only* works with phone numbers. (Or do you plan to add
   these as SIP/SIPS URI parameters too? If you did that, then
   there would be multiple ways to encode this, such as:
   <sip:+12125551234;cpc="police"@example.com;cpc="operator">;user=phone

- addresses with/without the parameter don't compare equal, so
     <tel:+12125551234>
   isn't equal to
     <tel:+12125551234;cpc="police">

I'm dubious of putting all these parameters into tel. They may be of 
some value as part of routing translations, but they are especially 
dubious as identity assertions. These are attributes of an identity, not 
part of the identity. The name can stay the same while the attributes 
change. (The police station shuts down, and later on the same number is 
reassigned to a porn shop.)

	Paul

	Paul

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 11 Nov 2005 07:58:56 +0100

inline

>   <sip:+12125551234;cpc="police"@example.com;cpc="operator">;user=phone

Yes, it would have to be defined as a valid parameters for various URI 
schemes.

>     <tel:+12125551234;cpc="police">

That's actually not true:  RFC3261 section 19.1.4 says
-  All other uri-parameters appearing in only one URI are
            ignored when comparing the URIs.

> I'm dubious of putting all these parameters into tel. They may be of some 
> value as part of routing translations, but they are especially dubious as 
> identity assertions. These are attributes of an identity, not part of the 
> identity. The name can stay the same while the attributes change. (The 
> police station shuts down, and later on the same number is reassigned to a 
> porn shop.)

Since the URI is inserted by / asserted by a proxy, the cpc parameter should 
get updated upon reassignment. Distinguishing porn shops from the police 
would be the responsibility of the operator.
It is not uncommon for URI parameters to change: user=phone can become 
user=ip and vice versa; it's only a temporary property of the identity.

However, there is some inconsistency in using URI parameters versus header 
parameters. "isfocus" for example is also a temporary property and appears 
as a header parameter. So "cpc" could be one too, except that PAID 
apparently does not allow parameters...

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Nov 2005 11:44:36 -0500

Inline.

	Paul

>            ignored when comparing the URIs.

I thought you had me there. Then I checked, and it turns out that 19.1.4 
only applies to sip/sips URIs. Comparison rules for TEL are in 3966. In 
section 4 of that it says:

    o  Parameters are compared according to 'pname', regardless of the
       order they appeared in the URI.  If one URI has a parameter name
       not found in the other, the two URIs are not equal.

>> dubious as identity assertions. These are attributes of an identity, 
>> not part of the identity. The name can stay the same while the 
>> attributes change. (The police station shuts down, and later on the 
>> same number is reassigned to a porn shop.)
> 
> Since the URI is inserted by / asserted by a proxy, the cpc parameter 
> should get updated upon reassignment. Distinguishing porn shops from the 
> police would be the responsibility of the operator.

Thats fine for future calls made from that source. But if I received a 
call from the police once upon a time and bookmarked the URI, I will be 
continuing to think it designates the police. Its then not entirely 
clear what will happen if I use it as a target for a future call, 
including that parameter. That is the inherent problem of embedding 
mutable properties into names.

> user=ip and vice versa; it's only a temporary property of the identity.

I disagree with that particular example. Two sip URIs that are the same 
except that one has user=phone and the other has user=ip are *different* 
names/identities. They may or may not represent the same resource.

> However, there is some inconsistency in using URI parameters versus 
> header parameters. "isfocus" for example is also a temporary property 
> and appears as a header parameter. So "cpc" could be one too, except 
> that PAID apparently does not allow parameters...

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 11 Nov 2005 21:20:35 +0100

Another thing: perhaps the calling party category should be expressed as an 
URN?

Jeoren

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Nov 2005 08:49:09 -0500

That is a possibility. It would require somebody to define the URN type.

If the CPC can only be expressed as one particular type of URN then 
there is little value over using some header with a well defined and 
regulated registration procedure for values.

I think the greatest value for URNs is when they go in a field that can 
handle a variety of URN or URI types. For instance Alert-Info can 
potentially use an assortment of URN types and other URI types as well.

	Paul

Jeroen van Bemmel wrote:
> Another thing: perhaps the calling party category should be expressed as 
> an URN?
> 
> Jeoren

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 14 Nov 2005 17:41:59 +0100

Paul,

My thought was inspired by the services drafts; a URN could express 
hierarchy:

Suppose I would want only calls from people working for an "emergency 
service" to call me. Then both calls from "cpc:sos.fire" and 
"cpc:sos.police" would get through

An enumeration of strings wouldn't allow this.

Jeroen

> If the CPC can only be expressed as one particular type of URN then there 
> is little value over using some header with a well defined and regulated 
> registration procedure for values.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Nov 2005 21:41:37 -0500

> An enumeration of strings wouldn't allow this.

Why not? "sos", "sos.fire" and "sos.police" are all strings.
In any case, you can set up any kind of hierarchical registry you want 
as part of defining the header, and you would still have to do that to 
define a new URN.

If there is an existing URN that fills the bill then I would be more 
easily convinced. (In particular, if the URN that will be defined for 
emergency services is suitable.) Or if there are other places where this 
might be used that would be able to take a URN, that would be a 
justification. But if all that is needed is a hierarchical set of names 
to be used in this one place then a URN just seems to be overkill.

	Paul

>> I think the greatest value for URNs is when they go in a field that 
>> can handle a variety of URN or URI types. For instance Alert-Info can 
>>> Another thing: perhaps the calling party category should be expressed 
>>> as an URN?
>>>
>>> Jeoren 
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 Nov 2005 22:37:08 -0500

Stepping back a sceond, I believe Paul has accurately characterized this 
as "p-cpc is to P-asserted-ID as sip-saml is to sip-identity". The main 
question to answer, then, is whether we want to specify a p-a-id 
equivalent for saml when we already have the saml mechanism under 
development? One of the reasons we did P-A-ID is that there wasn't yet 
sip-identity; it was considered a short term solution meant to be 
deprecated by our long term one. Do we want another short-term solution 
here?

Assuming for the moment that we do want some kind of short term 
solution; I also agree with Paul that ideally P-A-ID parameters would 
have been best, but P-A-ID doesn't allow it.  URI parameters is 
definitely not the right thing since the role is not a property of the 
URI; its a property of the asserted identity regardless of its scheme.

-Jonathan R.

Paul Kyzivat wrote:

>>>> Another thing: perhaps the calling party category should be 
>>>> expressed as an URN?
>>>>
>>>> Jeoren 
>>
>>
>>
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com