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

From: "GARCIN Sebastien RD-CORE-ISS" <[email-masked]>
Date: Wed, 16 Nov 2005 14:08:18 +0100

I believe that the debate is not "short term" versus "long term", do we only track solutions for the global internet or also look at solution fit for private administrative domains?

My understanding is that the P-header process was defined for the latter purpose and that solutions need not be exclusive.

sebastien 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Jonathan Rosenberg
Envoyé : mercredi 16 novembre 2005 04:37
À : Paul Kyzivat
Cc : 'James M. Polk'; [email-masked]; Anders Kristensen
Objet : Re: [Sipping] Comments on sipping-calling-party-category-01

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:

> 
> 
> Jeroen van Bemmel wrote:
> 
>> 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.
> 
> 
> 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
> 
>> Jeroen
>>
>>> 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
>>
>>
>>
> 
> _______________________________________________
> 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
> 

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

_______________________________________________
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

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Thu, 17 Nov 2005 16:13:04 -0600

On Nov 16, 2005, at 7:08 AM, GARCIN Sebastien RD-CORE-ISS wrote:

>
> I believe that the debate is not "short term" versus "long term",  
> do we only track solutions for the global internet or also look at  
> solution fit for private administrative domains?
>
> My understanding is that the P-header process was defined for the  
> latter purpose and that solutions need not be exclusive.

There is some legitimate and widespread concern about the efficacy of  
the "P-" process in conveying the depth and significance of the  
applicable usage constraints on an approach to future implementors.  
Like it or not, P-headers have become defacto standards in some  
cases, and this really isn't good.

My personal opinion is that the P- approach is fundamentally sound,  
but we've been overly-lax in enforcing  the thresholds established in  
RFC 3427.  However, it could be reasonably argued that this can't be  
enforced effectively, and that we should fall back to the higher bar  
of "standards track" for all SIP extensions.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 18 Nov 2005 18:29:28 -0500

GARCIN Sebastien RD-CORE-ISS wrote:

> I believe that the debate is not "short term" versus "long term", do
> we only track solutions for the global internet or also look at

Well, the difficulty is that "private administrateive domains" become 
connected to the public internet more easily and quickly then one would 
like.

> latter purpose and that solutions need not be exclusive.

On this specific topic I'm on the fence to be clear; I see the benefits 
of a "lighter" solution that works like P-A-ID and I believe that there 
are many service providers that will want that. But, I see it breaking 
down even more badly that P-A-ID will break down once interconnection 
becomes more broad.

-Jonathan R.