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

[OKUMURA Shinji <[e-mail]>]

Hi,

"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".)

I have another question in regard to the above.

When the entity that add a hi-entity require privacy service to
removed it, where should the entity set a priv-value "critical" ?
If it set "critical" in Privacy header of the request, all
hi-entities are removed. If in hi-targeted-to-uri, the privacy
service that does not support "history" will forward the request
without the change.

Is this correct? 

Regards,
Shinji


>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