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

["Dale Worley" <[e-mail]>]

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.

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.

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.

Dale