Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax

[Paul Kyzivat <[e-mail]>]

I also agree with the points Hadriel raised.
The one about the TEL URI is a major one.
(And no, there are no header parameters in TEL URIs.)

The backward compatibility issue is a real one, but seems like one that 
needs to be addressed.

	Thanks,
	Paul

Hans Erik van Elburg wrote:
> Yes, I agreed with most points you raised below. Question is if this can 
> be fixed in a backward compatible way, seems hard unfortunately
> 
> /Hans Erik
> 
> Hadriel Kaplan wrote:
>> Ignore that email - just realized it was done that way in the original 
>> RFC4424, so we're stuck with it for posterity's sake.  Blech.
>>
>> -hadriel
>>
>>  
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On 
>>> Behalf
>>> Of Hadriel Kaplan
>>> Sent: Saturday, July 11, 2009 4:17 PM
>>> To: Mary Barnes; Dale Worley; Francois Audet
>>> Cc: SIPCORE
>>> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax
>>>
>>>
>>> Howdy,
>>> I have some warning bell ringing in my head against this idea of 
>>> changing
>>> the Request-URI encoded in the HI header (the hi-targeted-to-uri) to
>>> include an embedded Reason or Privacy header.  I think the bell is 
>>> due to
>>> the following concerns:
>>>
>>> 1) Afaict, the Reason value is not an attribute/property of the URI - it
>>> is the History-Info mechanism's specific rerouting cause, i.e. it's a
>>> property of what caused the HI header field to be created, so it's a
>>> property of the header field.  The Privacy header is a little less 
>>> clear,
>>> but again ISTM that it's a command for the HI mechanism itself, and thus
>>> an attribute of the HI header field.  For example, one of the potential
>>> actions to be taken by a Proxy is to remove the HI entry entirely - not
>>> just the URI.
>>>
>>> 2) If it weren't for this added escaped URI header, the 
>>> hi-targeted-to-uri
>>> would be a literal copy of the original request-URI. (right?)  That 
>>> would
>>> provide a clean way of doing troubleshooting and target
>>> determination/matching, without exception checking for special things
>>> added by this RFC into the URI for its own purposes.
>>>
>>> 3) If we ever decide to create some way of securing the original URI in
>>> HI's, for example by signing it, it adds confusion or even breaks the
>>> signature if the original URI is not actually left alone.
>>>
>>> 4) While it may seem that embedded headers could not have appeared in 
>>> the
>>> received Request-URI to being with, in practice I have seen embedded
>>> headers in received SIP Request-URI's.  In particular, in INVITE's 
>>> created
>>> from REFER's, and in ENUM-routing cases.  In such cases there could
>>> theoretically be ambiguity whether the embedded header came from the HI
>>> mechanism vs. the actual request-URI.
>>>
>>> 5) The hi-targeted-to-uri can be a tel-uri (right?); can tel-URI's have
>>> embedded headers? (it's not a SIP-URI)
>>>
>>> -hadriel
>>>
>>>    
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On
>>>>       
>>> Behalf
>>>    
>>>> Of Mary Barnes
>>>> Sent: Friday, July 10, 2009 4:44 PM
>>>> To: Dale Worley; Francois Audet
>>>> Cc: SIPCORE
>>>> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax
>>>>
>>>> A couple points below [MB].
>>>>
>>>> Mary.
>>>>
>>>> -----Original Message-----
>>>> From: Worley, Dale (BL60:9D30)
>>>> Sent: Friday, July 10, 2009 3:24 PM
>>>> To: Audet, Francois (SC100:3055)
>>>> Cc: Barnes, Mary (RICH2:AR00); SIPCORE
>>>> Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax
>>>>
>>>> On Thu, 2009-07-09 at 14:07 -0400, Audet, Francois (SC100:3055) wrote:
>>>>      
>>>>> It's basically saying that the Privacy and Reason "escaped parameters"
>>>>>         would translate into headers if we were to created a 
>>>>> request based on
>>>>>         
>>>> it.
>>>>
>>>> I can't see any circumstances where we would want to create a request
>>>> that included the Privacy or Reason headers from a H-I entry.
>>>>
>>>> In regard to Privacy, if its value is "history", that means that the
>>>> particular H-I URI should be restricted.  But that is not the 
>>>> meaning of
>>>> adding the "Privacy: history" header to a request -- in the latter 
>>>> case,
>>>> History-Info should not be generated at all.  (Which is what I mean 
>>>> when
>>>> I say "the values of Privacy in History-Info do not have the same
>>>> semantics as the values of the Privacy header".)
>>>>
>>>> In regard to Reason, as far as I can tell, it is attached to an H-I
>>>> entry to show the response that was received to the request that was
>>>> sent to that URI.  Generating a request based on that H-I entry would
>>>> create a request to that same URI, containing a Reason header in the
>>>> request that *predicts* the response that the request will receive.
>>>>
>>>> Given that in no case would we want to generate and use (with the
>>>> implicit headers) a request based on the H-I entry's 
>>>> URI-with-headers, I
>>>> don't see why these data items are stored in headers attached to the
>>>> URI.
>>>> [MB] We discussed this in another thread and the motivation was the
>>>> reuse of existing headers rather than defining parameters that had the
>>>> same semantics and values. That was discussed at IETF-55 in Atlanta in
>>>> the SIPPING WG meeting in November 2002:
>>>> http://www.ietf.org/proceedings/02nov/slides/sipping-2/sld5.htm
>>>>
>>>> And, this makes sense in particular for Reason and perhaps lesser so 
>>>> for
>>>> Privacy.  And, as you say we would never use the Request URIs in these
>>>> hi-entrys to generate a request so this does not cause any problems.
>>>> The intent is not to add parameters to the Request URI for any reasons
>>>> other than to take advantage of the "clever" escaping mechanism 
>>>> provided
>>>> by HTTP and to avoid defining parameters with the same values as the
>>>> headers, both of which are not bad ideas. And, the normative text is
>>>> quite clear that this is the intent. [/MB]
>>>>
>>>> On Wed, 2009-07-08 at 19:25 -0400, Barnes, Mary (RICH2:AR00) wrote:
>>>>      
>>>>> As far as privacy, I'm not sure what you mean with regards to " This
>>>>> privacy value is an annotation of the URI, whereas the current syntax
>>>>> incorporates it *into* the URI."  The privacy value isn't incorporated
>>>>>         into the URI - it's an escaped parameter.
>>>>>         
>>>> It's an escaped parameter, but it *is* part of the URI -- see the
>>>> production "SIP-URI" in section 25.1 of RFC 3261.  And if you ask the
>>>> grammar, "What is the URI part of an H-I entry?" you will get back the
>>>> 'headers' as part of the URI.
>>>> [MB] See my comment above. Since we have specified clearly in the HI
>>>> ABNF and in the normative text, this URI needs to be appropriately
>>>> handled to derive the parameters. And, it is not abnormal to remove the
>>>> headers that are escaped in the URIs - basic HTTP.
>>>>
>>>> Similarly, any device or syntax which admits a SIP URI will allow 
>>>> you to
>>>> enter a string containing 'headers'.  Indeed, there is only one
>>>> situation where a SIP URI is possible but that URI cannot contain
>>>> 'headers', and that is as the request-URI of a request.  That isn't
>>>> specified in the syntax (which allows SIP-URI), but is a consequence of
>>>> the processing in section 19.1.5, which removes the 'headers' from the
>>>> supplied SIP URI and turns them into message headers.
>>>> [MB] Exactly and that's why it's not a problem. Since we are 
>>>> capturing a
>>>> Request URI, there is no conflict between the headers that we escape
>>>> since no other headers can be escaped in the Request URI.
>>>> [/MB]
>>>>
>>>> Dale
>>>>
>>>>
>>>> _______________________________________________
>>>> sipcore mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>       
>>> _______________________________________________
>>> sipcore mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>     
>> _______________________________________________
>> sipcore mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sipcore
>>   
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>