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

[Paul Kyzivat <[e-mail]>]

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.

>   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?

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.)

	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
>
>