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

[Shida Schubert <[e-mail]>]

Hi Paul;

 My comments inline.

On Jun 24, 2011, at 10:33 PM, Paul Kyzivat wrote:

> 
> 
> On 6/24/2011 8:16 AM, Shida Schubert wrote:
>> 
>> 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)
> 
> That seems about right. (I'm not sure about the tags, just because I haven't been following that closely.)
> 
>>  In that case, how do you think the privacy of the tel URI
>> should be handled?
> 
> I guess you are asking because a privacy header can't be affixed to a tel uri?
> 
> If so, that suggests to me that handling privacy by embedding a privacy header into the URI was a mistake.

 This wasn't what I was asking per se.  
 
 We can't express the desired way privacy is handled for tel URI due to the constrain 
you mentioned above, but what we can say in the draft is to suggest the use of Privacy 
header field instead of Privacy header embedded in the URI when tel URI is in the list 
of H-I which needs to be anonymized. 

 * Another question about anonymizing tel URI, AFAIK there is no guideline on how 
    one anonymizes tel URI? I guess if there is domain in "phone-context", we change that 
to "invalid.domain" or something. (May be in the security consideration?)

> 
>>  Should the proxy apply the same privacy policy that it would
>> apply to the SIP URI?
> 
> Oh. Do you mean that when privacy is applied by hiding things belonging to the proxy's domain, how does it decide that this should be hidden too?

 Yes. 

> 
> If it is hiding things because not hiding them would expose domain addresses, then there is no reason to hide the tel uri, since it doesn't expose a domain address.
> 
> NOTE: That is precisely why tel URIs are *not* equivalent to their sip "equivalent" URIs. The tel uri implies no domain - anyone wanting to call it is both free and obligated to seek out its own way of routing it. Calls to sip URIs are constrained to be routed based on the domain of the URI until reaching a server responsible for that domain.
> 
> For instance, if you have sip:[e-mail], and you have a device that has connectivity to both the pstn and internet, you are really obligated to route it to example.com. And if you currently only have pstn connectivity you ought not send it via the pstn.
> 
> But if you have tel:[phone], you are free to do whatever you want.
> 
> I know may devices will simply *assume* the sip uri is equivalent to a tel uri. But that isn't really proper. The device may have important features that can't work over a pstn connection.
> 
> (These comments are really from an individual, rather than chair, perspective.)

 So are you saying that privacy of tel URI shouldn't be a concern of a proxy that is 
handling the request, as long as the domain isn't exposed? 

 Regards
  Shida

> 
> 	Thanks,
> 	Paul
> 
>>  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
>> 
>>