Re: [Iptel] [Sipping] draft-mahy-iptel-cpc

["DOLLY, MARTIN C, ATTLABS" <mdolly at att.com>]

I agree cpc and oli should be associated with the PAI. 

-----Original Message-----
From: Alan Johnston [mailto:alan at sipstation.com] 
Sent: Tuesday, April 01, 2008 8:21 PM
To: Paul Kyzivat
Cc: Francois Audet; iptel at ietf.org; DOLLY, MARTIN C, ATTLABS;
sipping at ietf.org; DRAGE, Keith (Keith)
Subject: Re: [Sipping] draft-mahy-iptel-cpc

Paul Kyzivat wrote:
> Francois Audet wrote:
>   
>> Keith,
>>  
>> Tel URI vs SIP URI is one issue. My guess is Tel URI is OK, and it 
>> will map into a SIP URI fine. If we believe that this concept is 
>> applicable to URIs that are not telephone numbers, then it should be
a 
>> SIP URI parameter instead. Don't really care either way.
>>  
>> The other issue is "From:" header versus "P-Asserted-ID". I believe
this 
>> parameter is intended to be provided by the "network" and not the
UAC. 
>> So it would seem to me that it should be in P-Asserted-ID parameter 
>> header and not From header. Especially if RFC 4474 is used.
>>  
>> I think Paul Kyzivat was even proposing a P-Asserted-ID parameter.
That 
>> would work too.
>>     
>
> To be clear, I don't have any particular ax to grind about this 
> proposal. I just find it technically questionable. The semantics are 
> fuzzy, and the means to convey them seems inappropriate.
>
> Ignoring the fuzziness, the semantics are such that they must be 
> asserted by some trusted party, not the UAC. And so they don't make 
> sense in most places that a TEL URI might appear. About the only place

> they seem to make sense is a PAI. If that is the only place they make 
> sense, then adding them to that header makes more sense. Also, there
is 
> no such thing as P- parameters for TEL, but this seems to be something

> with the applicability characteristics of a P- header, which is
another 
> reason to go for PAI.
>   

A long time ago in a galaxy far, far away, I proposed CPC be added to 
the Remote-Party-ID header field (remember that?) which 
P-Asserted-Identity eventually replaced.  It was added to that I-D, but 
I don't recall why this info never made it into P-A-I.

I agree that it makes better sense there than as a tel URI parameter.

Thanks,
Alan

> I can see that the information conveyed by this parameter is indeed 
> useful information to have, if one has a reason to believe it. And it 
> would be equally useful if the request originated at a SIP UAC rather 
> than in the PSTN, and also if the source had a non-numeric sip
identity 
> rather than a telephone number identity. (Surely you would like to
know 
> if the IM you just received was from somebody in a prison.)
>
> The only reason I can see to exclude SIP originated calls and 
> non-numeric URIs is because we don't know how to accurately determine 
> the information or how to ascertain that it it has been conveyed 
> truthfully. But that is true for telephone numbers too, as well as
calls 
> gatewayed from the pstn to sip. Until we know how to do that on the
open 
> internet this seems to fall in the realm of closed gardens and P-
headers.
>
> 	Paul
>
>   
>>
------------------------------------------------------------------------
>>     *From:* sipping-bounces at ietf.org
[mailto:sipping-bounces at ietf.org]
>>     *On Behalf Of *DRAGE, Keith (Keith)
>>     *Sent:* Saturday, March 29, 2008 16:26
>>     *To:* DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel at ietf.org;
>>     sipping at ietf.org
>>     *Subject:* Re: [Sipping] draft-mahy-iptel-cpc
>>
>>     My understanding of the cpc work in iptel is that is currently
held
>>     pending the approval of the internet draft defining the approval
>>     regime for tel URI parameters. I believe the current status of
this
>>     is to make the approval of tel URI parameters standards track
>>     required, although that could have altered - not in a position to
>>     look it up currently.
>>      
>>     Which brings us to the next issue in that I understand that at
least
>>     some of the TISPAN people want to use this as a SIP URI parameter
as
>>     well as a tel URI parameter. These are two distinct sets of
>>     parameters and therefore a tel URI parameter does not
automatically
>>     become a SIP URI parameter.
>>      
>>     Is this so? Are there any indications which we want to be able to
>>     use with SIP URIs as well as tel URIs.
>>      
>>     regards
>>      
>>     Keith
>>      
>>      
>>
>>
------------------------------------------------------------------------
>>         *From:* sipping-bounces at ietf.org
>>         [mailto:sipping-bounces at ietf.org] *On Behalf Of *DOLLY,
MARTIN
>>         C, sbcuid
>>         *Sent:* Friday, March 28, 2008 6:15 PM
>>         *To:* Sumit Garg; iptel at ietf.org; sipping at ietf.org
>>         *Subject:* Re: [Sipping] draft-mahy-iptel-cpc
>>
>>         Sumit,
>>          
>>         For as long as the values are clear, this approach would be
>>         acceptable.
>>          
>>         Martin
>>
>>
------------------------------------------------------------------------
>>         *From:* sipping-bounces at ietf.org
>>         [mailto:sipping-bounces at ietf.org] *On Behalf Of *Sumit Garg
>>         *Sent:* Friday, March 28, 2008 2:09 PM
>>         *To:* iptel at ietf.org; sipping at ietf.org
>>         *Subject:* Re: [Sipping] draft-mahy-iptel-cpc
>>
>>         I agree with Ian, we should avoid multiple parameters.
>>
>>         The way a lot of stuff is done in tel-uri might be useful....
>>
>>          
>>
>>         We would only  need 1 parameter:  i.)
user-type=<cpc/oli-values>
>>
>>                         Renamed /to user-type as we do not
necessarily
>>         tie it to originating side.....we might find other needs in
the
>>         future./
>>
>>          
>>
>>         For the current scenario, the number itself would help the
>>         implementation decide whether it is CPC/OLI.
>>
>>         A global number inherently has a country code which would
help
>>         decide the valid values (cpc/oli)
>>
>>         Otherwise the phone-context could be used to decide the same.
>>
>>          
>>
>>         For implementations which use neither..i.e. for which context
is
>>         implicit...they would implicitly know whether  it is cpc/oli.
>>
>>          
>>
>>         -Sumit
>>
>>          
>>
>>          
>>
>>         "The reasonable man adapts himself to the world; the
>>         unreasonable one persists in trying to adapt the world to
>>         himself. Therefore all progress depends on the unreasonable
man."
>>         -- George Bernard Shaw
>>
>>         *From:* Ian Elz [mailto:ian.elz at ericsson.com]
>>         *Sent:* Friday, March 28, 2008 12:10 PM
>>         *To:* DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel at ietf.org;
>>         sipping at ietf.org
>>         *Subject:* RE: [Sipping] draft-mahy-iptel-cpc
>>
>>          
>>
>>         Martin,
>>
>>          
>>
>>         I saw you email with the list of values.
>>
>>          
>>
>>         I was not proposing to remove the values but to combine them
>>         into an extended list which encompassed both OLI and CPC.
ANSI
>>         does not use CPC to any extent while ETSI/CCITT uses CPC for
the
>>         same purpose as ANSI uses OLI.
>>
>>          
>>
>>         An expanded combined single parameter may be suitable for all
>>         the required values.
>>
>>          
>>
>>         If you look at what is proposed by 3GPP you will see that it
is
>>         proposed to reduce the different CCITT operator CPC values by
>>         using 'language' in Accept-Contact. There may be options to
use
>>         similar techniques to enable all the OLI values to be handled
>>         correctly.
>>
>>         /Ian Elz/
>>
>>         /System Manager/
>>         /DUCI LDC UK/
>>         /(Lucid Duck)/
>>
>>         /Office: + 44 24 764 35256/
>>         /gsm: +44 7801723668/
>>         /ian.elz at ericsson.com/
>>
>>
------------------------------------------------------------------------
>>     
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sip at ietf.org for new developments of core SIP
>
>
>   

_______________________________________________
Iptel mailing list
Iptel at ietf.org
https://www.ietf.org/mailman/listinfo/iptel