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

[Ted Hardie <[e-mail]>]

At 4:25 PM -0700 3/29/08, DRAGE, Keith (Keith) wrote:
>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.
> 

The draft is at :

http://www.ietf.org/internet-drafts/draft-ietf-iptel-tel-reg-05.txt

In the new version of the draft, the registration policy stuff is in 4.2:

4.2.  Registration Policy for tel URI Parameters

   As per the terminology in [6] and actions accorded to such a role,
   the registration policy for tel URI parameters shall be
   "Specification Required, Designated Expert" (the former implicitly
   implies the latter.)

   The Designated Expert when deliberating on whether to include a new
   parameter in the tel URI registry may use the criteria provided below
   to reach a decision (this is not an exhaustive list but
   representative of the issues to consider when rendering an equitable
   decision):

   o  If the tel URI -- with the parameter under consideration -- will
      be converted to a URI used by other signaling protocols such as
      the Session Initiation Protocol (SIP [4]) or H.323 [7], then the
      expert must consider whether this parameter merely encapsulates
      signaling information that is not meaningful to the processing of
      requests in the domain of the converted URI.  For example, certain
      Integrated Services Digital Network (ISDN) User Part (ISUP, [8])
      parameters have no equivalent corollary in SIP; thus their
      presence or absence in a SIP URI will not hinder the normal rules
      for processing that URI.  Other parameters may affect the normal
      processing rules associated with the URI; in such cases, the
      expert must consider carefully the ramifications, if any, of the
      presence of such parameters.

   o  Certain parameters of a tel URI can be optional.  These parameters
      act as metadata about the identifier in the tel URI.  Optional
      parameters should provide additional information to a service for
      which they apply instead of acting as enablers of that service in
      the first place.  The service must continue to be invoked and
      operate normally even in the absence of these parameters.



			regards,
				Ted
>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: [e-mail] [mailto:[e-mail]] On Behalf Of DOLLY, MARTIN C, sbcuid
>Sent: Friday, March 28, 2008 6:15 PM
>To: Sumit Garg; [e-mail]; [e-mail]
>Subject: Re: [Sipping] draft-mahy-iptel-cpc
>
>Sumit,
> 
>For as long as the values are clear, this approach would be acceptable.
> 
>Martin
>
>
>From: [e-mail] [mailto:[e-mail]] On Behalf Of Sumit Garg
>Sent: Friday, March 28, 2008 2:09 PM
>To: [e-mail]; [e-mail]
>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:[e-mail]]
>Sent: Friday, March 28, 2008 12:10 PM
>To: DOLLY, MARTIN C, sbcuid; Sumit Garg; [e-mail]; [e-mail]
>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: [phone]
>[e-mail]
>
>
>Content-Type: text/plain; name="ATT00001.txt"
>Content-Description: ATT00001.txt
>Content-Disposition: attachment; filename="ATT00001.txt"; size=358;
>	creation-date="Sat, 29 Mar 2008 16:26:41 GMT";
>	modification-date="Sat, 29 Mar 2008 16:26:41 GMT"
>
>Attachment converted: Macintosh HD:ATT00001 878.txt (TEXT/ttxt) (00728182)

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP