Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis

Shida Schubert <shida@ntt-at.com> Fri, 24 June 2011 12:16 UTC

Return-Path: <shida@ntt-at.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAEE9E803F for <sipcore@ietfa.amsl.com>; Fri, 24 Jun 2011 05:16:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Level:
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmhSdNROf4d6 for <sipcore@ietfa.amsl.com>; Fri, 24 Jun 2011 05:16:55 -0700 (PDT)
Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8E19E8018 for <sipcore@ietf.org>; Fri, 24 Jun 2011 05:16:55 -0700 (PDT)
Received: from [125.192.75.244] (port=49761 helo=[192.168.11.3]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <shida@ntt-at.com>) id 1Qa5JP-00015b-TW; Fri, 24 Jun 2011 07:16:40 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Shida Schubert <shida@ntt-at.com>
In-Reply-To: <4DFFB175.5080507@cisco.com>
Date: Fri, 24 Jun 2011 21:16:37 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <56BD4DB5-2808-4EA5-BF44-BEC1E5AB0874@ntt-at.com>
References: <4DEC205A.5040503@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E36022D@ESESSCMS0356.eemea.ericsson.se> <2FDD10D8-6DF3-4D77-B300-C05C2AB5D3A2@agnada.com> <7F2072F1E0DE894DA4B517B93C6A0585194E3E71BA@ESESSCMS0356.eemea.ericsson.se> <4DFFB175.5080507@cisco.com>
To: Paul Kyzivat <pkyzivat@cisco.com>
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator465.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ntt-at.com
X-BWhitelist: no
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: flh1agj244.tky.mesh.ad.jp ([192.168.11.3]) [125.192.75.244]:49761
X-Source-Auth: shida@agnada.com
X-Email-Count: 7
X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t
Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org, Robert Sparks <RjS@nostrum.com>, "SIPCORE \(Session Initiation Protocol Core\) WG" <sipcore@ietf.org>, SIPCORE Chairs <sipcore-chairs@tools.ietf.org>
Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jun 2011 12:16:55 -0000

Paul;

 Are you suggesting to include three hi-entries, 
whenever an entity retargeting the tel-URI 
logs it to H-I?

e.g. 

 History-Info : <tel:2222222>;index=1
 History-Info : <sip:{sip representation of tel URI}>; index=1.1; mp=1 
 History-Info : <sip:{retarget URI}>;index=1.2, rc=1.1 
  (based on the new semantics Hadriel suggested)

 In that case, how do you think the privacy of the tel URI 
should be handled? 

 Should the proxy apply the same privacy policy that it would 
apply to the SIP URI? 

 Regards
  Shida

On Jun 21, 2011, at 5:45 AM, Paul Kyzivat wrote:

> (as individual)
> 
> On 6/17/2011 3:25 AM, Christer Holmberg wrote:
> 
>>>> 3. Tel to Sip transformation: History-Info (technical)
>>>> 		
>>>> Related to the previous question, the text doesn't indicate whether the transformation from Tel to Sip should be recorded in an History-Info header field. The Request-URI is, after all,
>>>> changed.
>>> 		
>>> 
>>> I don't know if we need to add anything specific for this. The draft doesn't limit the
>>> behavior of the entity recording H-I to only record SIP-URI, it just says to record the
>>> R-URI.
>> 
>> Based on the comments I get, the text seems to indicate that you shouldn't insert a Tel in a History-Info in the first place. Instead you should transform it to a SIP-URI before inserting it.
> 
> I agree with Christer (!!!) that the transformation from tel: to sip: *is* a change, and if you care about H-I then this ought to be recorded.
> 
> (This is not just a superficial change in representation - it is a *semantic* change, because different processing rules apply to sip URIs that tel URIs.)
> 
> There isn't even a guarantee that a proxy will have a suitable way to re-represent a tel uri as a sip URI.
> 
> So I think this calls for some sort of explanation. I guess its lucky that if you do create H-I entries for this, that its the translated (sip) URI that gets the parameters added. So its at least *possible* to do this.
> 
> 	Thanks,
> 	Paul