Re: [Iptel] [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@ericsson.com] 
Sent: Friday, March 28, 2008 12:10 PM
To: DOLLY, MARTIN C, sbcuid; Sumit Garg; iptel@ietf.org;
sipping@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@ericsson.com 

________________________________