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

["Mary Barnes" <[e-mail]>]

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