Subject: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-target

From: "Dale Worley" <[email-masked]>
Date: Tue, 07 Jul 2009 15:56:00 -0400

Given the number of hi-target values and the rate at which we have been
changing them, perhaps we should have them be values of a single
parameter, rather than separate parameters.  That would allow
extensibility of this set with fewer interoperability problems.  E.g.,
change the BNF to:

   hi-target = "t" EQUAL ( "noop" / "predetermined" / "reg-uri" /
                           "reg-uri-alias" / "mapped" )

Dale

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 8 Jul 2009 10:40:35 -0500

Dale,

I'm not sure what the alternative you suggest buys us.  The current ABNF
already provides the concept of a single parameter - the difference I
see is whether we have the "t=" prepended to the parameter value. I'm
not seeing that your ABNF change doesn't add extensibility either.  

Also, the change to the parameter names hasn't been so much that there
are new mechanisms being determined, but rather how we want to annotate
the current mechanisms by which the targets are determined.  So, I would
not anticipate much churn once we get agreement on the tagging. But, we
could certainly build extensibility by adding a generic-parm to the set
of possible values.  However, that suggests to me that we might want an
IANA registry for the values.  My concern here would be of course, that
rather than having the tags reflect how core SIP has determined the new
target, folks would be wanting to add tags that are service specific,
which contradicts the intent of the hi-target. 

Regards,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Worley, Dale (BL60:9D30)
Sent: Tuesday, July 07, 2009 2:56 PM
To: SIPCORE
Subject: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-target

Dale

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 08 Jul 2009 14:22:08 -0400

> not seeing that your ABNF change doesn't add extensibility either.  

The text currently allows exactly one of 5 parameters.  In situations
like that, I prefer to model the situation as alternative values of a
single parameter (whose value is an enumeration type).

> My concern here would be of course, that

Yes, I can see quite a danger in that.  Ironically, what we are arguing
for is *minimizing* extensibility in dimension, in order to avoid
proprietary extensions.

I concede this point.

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 08 Jul 2009 14:32:08 -0400

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:[email-masked]?Privacy=history&Reason=SIP%3Bcause%3D486>;index=1.2;mapped

where I would expect:

  <sip:[email-masked]?Reason=SIP%3Bcause%3D486>;index=1.2;mapped;privacy=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

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 8 Jul 2009 18:25:10 -0500

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

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

where I would expect:

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

Dale

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 9 Jul 2009 13:07:12 -0500

I guess it's somewhat historical.

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.

This whole concept falls into the category of "it came from HTTP so it must
be good (TM)". 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Worley, Dale 
> (BL60:9D30)
> Sent: Wednesday, July 08, 2009 11:32
> Subject: [sipcore] 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:
> 
>   
> 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
> 
>

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 10 Jul 2009 16:24:24 -0400

> 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
> 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

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 10 Jul 2009 15:43:30 -0500

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.

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

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 10 Jul 2009 19:36:33 -0500

While it's debatable if it was the right choice back in 2002, it
seems a bit late to change it now. Especially since it will not
be backwards compatible.

> From: Barnes, Mary (RICH2:AR00) 
> Sent: Friday, July 10, 2009 13:44
> To: Worley, Dale (BL60:9D30); Audet, Francois (SC100:3055)
> Cc: SIPCORE
> > 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 
> 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:
> 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]
> 
> to " This 
> 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
> 
> 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 11 Jul 2009 16:16:51 -0400

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

> From: [email-masked] [mailto:[email-masked]] 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
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 11 Jul 2009 17:11:48 -0400

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

> Of Hadriel Kaplan
> Sent: Saturday, July 11, 2009 4:17 PM
> To: Mary Barnes; Dale Worley; Francois Audet
> Cc: SIPCORE
> 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.
> 
> Behalf

---

From: Hans Erik van Elburg <[email-masked]>
Date: Sun, 12 Jul 2009 11:54:52 +0200

Yes, I agreed with most points you raised below. Question is if this can 
be fixed in a backward compatible way, seems hard unfortunately

/Hans Erik

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 12 Jul 2009 21:24:45 -0400

I also agree with the points Hadriel raised.
The one about the TEL URI is a major one.
(And no, there are no header parameters in TEL URIs.)

The backward compatibility issue is a real one, but seems like one that 
needs to be addressed.

	Thanks,
	Paul

Hans Erik van Elburg wrote:
>> 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
>>
>>  
>>>>> request based on
>>>> capturing a

---

From: "Francois Audet" <[email-masked]>
Date: Sun, 12 Jul 2009 19:59:11 -0700

Yeah, exactly. My thoughts too.

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 13 Jul 2009 18:11:40 +0900

Hi,

"Dale Worley" <[email-masked]>
>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

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 30 Jul 2009 16:52:20 -0400

> seems a bit late to change it now. Especially since it will not

I think I've already mentioned that I don't see us changing that
feature.  But I wanted to review it to understand why it was done that
way.

Dale