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

From: "Francois Audet" <[email-masked]>
Date: Tue, 1 Apr 2008 17:09:57 -0500

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.

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
	Sent: Saturday, March 29, 2008 16:26
	To: DOLLY, MARTIN C, sbcuid; Sumit Garg; [email-masked]; [email-masked]
	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: [email-masked] [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C, sbcuid
		Sent: Friday, March 28, 2008 6:15 PM
		To: Sumit Garg; [email-masked]; [email-masked]
		Subject: Re: [Sipping] draft-mahy-iptel-cpc

		Sumit,
		 
		For as long as the values are clear, this approach would be acceptable.
		 
		Martin

________________________________

		From: [email-masked] [mailto:[email-masked]] On Behalf Of Sumit Garg
		Sent: Friday, March 28, 2008 2:09 PM
		To: [email-masked]; [email-masked]
		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:[email-masked]] 
		Sent: Friday, March 28, 2008 12:10 PM
		To: DOLLY, MARTIN C, sbcuid; Sumit Garg; [email-masked]; [email-masked]
		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 
		[email-masked] 

________________________________

_______________________________________________
Sipping mailing list  https://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: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Apr 2008 19:44:01 -0400

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

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.

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:* [email-masked] [mailto:[email-masked]]
>     *On Behalf Of *DRAGE, Keith (Keith)
>     *Sent:* Saturday, March 29, 2008 16:26
>     *To:* DOLLY, MARTIN C, sbcuid; Sumit Garg; [email-masked];
>     [email-masked]
>     *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.
>      
>         ------------------------------------------------------------------------
>         *From:* [email-masked]
>         [mailto:[email-masked]] *On Behalf Of *DOLLY, MARTIN
>         C, sbcuid
>         *Sent:* Friday, March 28, 2008 6:15 PM
>         *To:* Sumit Garg; [email-masked]; [email-masked]
>         *Subject:* Re: [Sipping] draft-mahy-iptel-cpc
> 
>         Sumit,
>          
>         ------------------------------------------------------------------------
>         *From:* [email-masked]
>         [mailto:[email-masked]] *On Behalf Of *Sumit Garg
>         *Sent:* Friday, March 28, 2008 2:09 PM
>         *To:* [email-masked]; [email-masked]
>         *Subject:* Re: [Sipping] draft-mahy-iptel-cpc
> 
>         The way a lot of stuff is done in tel-uri might be useful….
> 
>          
> 
>                         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.
> 
>         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:[email-masked]]
>         *Sent:* Friday, March 28, 2008 12:10 PM
>         *To:* DOLLY, MARTIN C, sbcuid; Sumit Garg; [email-masked];
>         [email-masked]
>         *Subject:* RE: [Sipping] draft-mahy-iptel-cpc
> 
>          
> 
>         Martin,
> 
>          
> 
>         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.
> 
>          
> 
>         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/
>         /[email-masked]/
> 
>         ------------------------------------------------------------------------

---

From: Alan Johnston <[email-masked]>
Date: Tue, 01 Apr 2008 19:21:26 -0500

> with the applicability characteristics of a P- header, which is another 

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

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Tue, 1 Apr 2008 19:40:09 -0500

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

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

Paul Kyzivat wrote:
>> I think Paul Kyzivat was even proposing a P-Asserted-ID parameter.
That 
>> would work too.

Thanks,
Alan

>>     *From:* [email-masked]
[mailto:[email-masked]]
>>         tie it to originating side.....we might find other needs in
the
>>         A global number inherently has a country code which would
help
>>         decide the valid values (cpc/oli)
>>
>>         implicit...they would implicitly know whether  it is cpc/oli.
>>
>>          
>>
>>         -Sumit
>>
>>          
>>
>>          
>>
>>         using 'language' in Accept-Contact. There may be options to
use