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

["Francois Audet" <[e-mail]>]

Yeah, exactly. My thoughts too.


On Jul11 2009 14:11 , "Hadriel Kaplan" <[e-mail]> 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