Ignore that email - just realized it was done that way in the original RFC4424, so we're stuck with it for posterity's sake.  Blech.

-hadriel

> -----Original Message-----
> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf
> Of Hadriel Kaplan
> Sent: Saturday, July 11, 2009 4:17 PM
> To: Mary Barnes; Dale Worley; Francois Audet
> Cc: SIPCORE
> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax
> 
> 
> Howdy,
> I have some warning bell ringing in my head against this idea of changing
> the Request-URI encoded in the HI header (the hi-targeted-to-uri) to
> include an embedded Reason or Privacy header.  I think the bell is due to
> the following concerns:
> 
> 1) Afaict, the Reason value is not an attribute/property of the URI - it
> is the History-Info mechanism's specific rerouting cause, i.e. it's a
> property of what caused the HI header field to be created, so it's a
> property of the header field.  The Privacy header is a little less clear,
> but again ISTM that it's a command for the HI mechanism itself, and thus
> an attribute of the HI header field.  For example, one of the potential
> actions to be taken by a Proxy is to remove the HI entry entirely - not
> just the URI.
> 
> 2) If it weren't for this added escaped URI header, the hi-targeted-to-uri
> would be a literal copy of the original request-URI. (right?)  That would
> provide a clean way of doing troubleshooting and target
> determination/matching, without exception checking for special things
> added by this RFC into the URI for its own purposes.
> 
> 3) If we ever decide to create some way of securing the original URI in
> HI's, for example by signing it, it adds confusion or even breaks the
> signature if the original URI is not actually left alone.
> 
> 4) While it may seem that embedded headers could not have appeared in the
> received Request-URI to being with, in practice I have seen embedded
> headers in received SIP Request-URI's.  In particular, in INVITE's created
> from REFER's, and in ENUM-routing cases.  In such cases there could
> theoretically be ambiguity whether the embedded header came from the HI
> mechanism vs. the actual request-URI.
> 
> 5) The hi-targeted-to-uri can be a tel-uri (right?); can tel-URI's have
> embedded headers? (it's not a SIP-URI)
> 
> -hadriel
> 
> > -----Original Message-----
> > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
> Behalf
> > Of Mary Barnes
> > Sent: Friday, July 10, 2009 4:44 PM
> > To: Dale Worley; Francois Audet
> > 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
> >
> >
> > _______________________________________________
> > sipcore mailing list
> > sipcore@ietf.org
> > https://www.ietf.org/mailman/listinfo/sipcore
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore