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

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

While it's debatable if it was the right choice back in 2002, it
seems a bit late to change it now. Especially since it will not
be backwards compatible.

> -----Original Message-----
> From: Barnes, Mary (RICH2:AR00) 
> Sent: Friday, July 10, 2009 13:44
> To: Worley, Dale (BL60:9D30); Audet, Francois (SC100:3055)
> 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
> 
> 
>