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

[Shida Schubert <[e-mail]>]

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:[phone]>;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