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

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

The Privacy (and Reason) header parameters are escaped in the URI so
that those headers could be reused rather than defining parameters with
the same semantics specific to the History-Info header. 
This mechanism is described in the normative section of 4244/4244bis. 

This makes absolute sense for the Reason, since we are capturing the
exact value.  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. When the
hi-entries are referenced, the UAS/application does need to be handle
both the Reason and Privacy headers that might be escaped in the URI,
but again that's part of the normative behavior for entities that
support 4244/4244bis.

Mary. 

-----Original Message-----
From: Worley, Dale (BL60:9D30) 
Sent: Wednesday, July 08, 2009 1:32 PM
To: Barnes, Mary (RICH2:AR00)
Cc: SIPCORE
Subject: draft-barnes-sipcore-rfc4244bis - privacy syntax

I'm curious why the privacy attribute of an hi-targeted-to-uri is
specified by adding a header-parameter to the URI, rather than being
given as a field-parameter.  That is, an example of the current syntax
is:

 
<sip:[e-mail]?Privacy=history&Reason=SIP%3Bcause%3D486>;index=1
.2;mapped

where I would expect:

 
<sip:[e-mail]?Reason=SIP%3Bcause%3D486>;index=1.2;mapped;privac
y=history

This privacy value is an annotation of the URI, whereas the current
syntax incorporates it *into* the URI.  And indeed, to reconstitute the
actual historical request-URI, one has to remove the Privacy header from
the URI part of the name-addr, that is, the stuff inside <...>.
(Although given that the historical URI can have had no header
parameters (due its use as a request-URI), that processing step is not
ambiguous.)

In addition, the values of the 4244 Privacy header do not have exactly
the same semantics as the same tokens used as values of the Privacy
header.

I guess that for compatibility with RFC 4244, we have to continue to
record privacy and reason information in the URI this way, but I'm
curious what the motivation was for this rather unusual way to represent
this information.

Dale