Subject: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt

From: [email-masked]
Date: Mon, 14 Feb 2011 07:15:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF.

	Title           : An Extension to the Session Initiation Protocol (SIP) for Request History Information
	Author(s)       : M. Barnes, et al.
	Filename        : draft-ietf-sipcore-rfc4244bis-03.txt
	Pages           : 48
	Date            : 2011-02-14

This document defines a standard mechanism for capturing the history
information associated with a Session Initiation Protocol (SIP)
request.  This capability enables many enhanced services by providing
the information as to how and why a SIP request arrives at a specific
application or user.  This document defines an optional SIP header
field, History-Info, for capturing the history information in
requests.  The document also defines SIP header field parameters for
the History-Info and Contact header fields to tag the method by which
the target of a request is determined.  In addition, this document
defines a value for the Privacy header field specific to the History-
Info header field.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Mary Barnes <[email-masked]>
Date: Mon, 14 Feb 2011 09:42:00 -0600

Apologies for the very lengthy delay in getting the document updated.

The changes are quite extensive based on all the feedback and include the
following:
1) Lots of editorial:
a) Reorganized sections similar to the RFC 4244 order - i.e., introduce
header field parameters and syntax first, then describe how the functional
entities use the header.  This removes redundant  (and often inconsistent)
text describing the parameters.
b) Expanded use of "header" to "header field"
c) More precision in terms of "escaping" of the Privacy and Reason headers
in the hi-targeted-to-uri (versus "adding"/"setting"/etc. them to the
hi-entry).
d) Consistent use of parameter names (i.e., hi-entry versus entry, hi-target
versus target, etc.)
e) Moved item 6 in the Index section to the section on Response handling
f) Removed last remaining vestiges of inline references to requirements.

2) Clarifications of functionality/applicability including:
a)  which messages may contain History-Info
b)  removing security text with regards to being able to figure out if there
are missing entries when using TLS (issue #44)
c) More complete information on the new header field parameters as they
relate to the hi-target parameter.
d) Changed wording from passive to active for normative statements in many
cases and removed superfluous normative language.

3) Rewrite of the Privacy section to address issues and splitting into the
setting of the Privacy header fields and the processing/application of the
privacy header field priv-values.

4) Rewrite of the Reason header field section - simplifying the text and
adding back the RFC 4244 text with regards to the use of the Reason header
field in cases of internal retargeting.

I did attempt to cover all the comments, but since alot of the relevant text
changed, it's possible that I missed some comments.   However, we're hoping
that folks will find this version to be easier to follow.

Regards,
Mary.

On Mon, Feb 14, 2011 at 9:15 AM, <[email-masked]> wrote:

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

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 16 Feb 2011 11:48:18 +0100

It will also take me a long time to review it, but one comment with impact in a lot of places.

We use the terms "escape", "escaped" and "escaping" frequently in the draft when talking about including a Privacy or Reason header field in the Headers component of a SIP or SIPS URI. RFC 3261 does not use any of these terms for that purpose. On the contrary, these terms are to do with character representation. So I find it very confusing using these terms in 4244bis when talking about placing a Privacy or Reason header field in a URI.

Of course, it is true that within a Privacy or Reason header field within the Headers component of a SIP or SIPS URI, certain characters will need escaping (as shown in examples). But if we need to talk about this, we should talk about character escaping - I think in the majority of cases (all cases?) we are talking about the entire header field where it fits within the URI (i.e., behind "?") - not specifically about character representation.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mary Barnes
> Sent: 14 February 2011 15:42
> To: SIPCORE
> Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt
> 
> The changes are quite extensive based on all the feedback and 
> include the following: 
> 1) Lots of editorial:
> a) Reorganized sections similar to the RFC 4244 order - i.e., 
> introduce header field parameters and syntax first, then 
> describe how the functional entities use the header.  This 
> removes redundant  (and often inconsistent) text describing 
> the parameters.
> c) More precision in terms of "escaping" of the Privacy and 
> Reason headers in the hi-targeted-to-uri (versus 
> "adding"/"setting"/etc. them to the hi-entry).
> d) Consistent use of parameter names (i.e., hi-entry versus 
> entry, hi-target versus target, etc.)
> b)  removing security text with regards to being able to 
> figure out if there are missing entries when using TLS (issue #44)
> c) More complete information on the new header field 
> parameters as they relate to the hi-target parameter.  
> d) Changed wording from passive to active for normative 
> statements in many cases and removed superfluous normative language. 
> 
> 
> 3) Rewrite of the Privacy section to address issues and 
> splitting into the setting of the Privacy header fields and 
> the processing/application of the privacy header field priv-values. 
> 
> 4) Rewrite of the Reason header field section - simplifying 
> the text and adding back the RFC 4244 text with regards to 
> the use of the Reason header field in cases of internal retargeting. 
> 
> I did attempt to cover all the comments, but since alot of 
> the relevant text changed, it's possible that I missed some 
> comments.   However, we're hoping that folks will find this 
> version to be easier to follow. 
> 
> Regards,
> Mary. 
> 
> 	       Title           : An Extension to the Session 
> Initiation Protocol (SIP) for Request History Information

---

From: Mary Barnes <[email-masked]>
Date: Wed, 16 Feb 2011 13:14:52 -0600

Hi John,

I fully agree that RFC 3261 doesn't specifically describe the use of
escaping in the manner used in 4244bis (and 4244).  But, that was the term
that was suggested to describe the behavior in RFC 4244 - it's way too long
ago to remember the discussion that led to the use of the term or whether
anyone ever raised an issue about the inconsistency before.   The previous
feedback for 4244bis was that we needed to be clear as to how the Reason and
Privacy were "captured" in the History-Info header field.  If folks don't
think the term escape is appropriate, then what term is preferred?  I guess
we could just say that the Reason and Privacy header fields are "added" to
the hi-targeted-to-uri using the " "?" mechanism" in the hi-targeted-to-uri,
which is consistent with the terminology used in RFC 3261.  Another thought
would be to include a description of "escape" as used in this document in
the terminology section.

Thanks,
Mary.

On Wed, Feb 16, 2011 at 4:48 AM, Elwell, John <
[email-masked]> wrote:

> We use the terms "escape", "escaped" and "escaping" frequently in the draft
> when talking about including a Privacy or Reason header field in the Headers
> component of a SIP or SIPS URI. RFC 3261 does not use any of these terms for
> that purpose. On the contrary, these terms are to do with character
> representation. So I find it very confusing using these terms in 4244bis
> when talking about placing a Privacy or Reason header field in a URI.
>
> Of course, it is true that within a Privacy or Reason header field within
> the Headers component of a SIP or SIPS URI, certain characters will need
> escaping (as shown in examples). But if we need to talk about this, we
> should talk about character escaping - I think in the majority of cases (all
> cases?) we are talking about the entire header field where it fits within
> the URI (i.e., behind "?") - not specifically about character
> representation.
>
> John
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 16 Feb 2011 21:06:14 +0100

Mary,

In fact what we are doing is placing these header fields in the Headers component of the SIP/SIPS URI - isn't that the proper way to describe it? I know the escape terminology has been in the draft for a long time, and if others are happy I guess I can live with it. Perhaps there are precedents in other RFCs. But I am not sure how somebody unfamiliar with this terminology would interpret it.

By the way, what if we have a tel: URI? I don't think that supports "escaped" header fields. Do our requirements for inserting "escaped" header fields apply only when the URI is SIP or SIPS?

John 

> From: Mary Barnes [mailto:[email-masked]] 
> Sent: 16 February 2011 19:15
> To: Elwell, John
> Cc: SIPCORE
> I fully agree that RFC 3261 doesn't specifically describe the 
> use of escaping in the manner used in 4244bis (and 4244).  
> But, that was the term that was suggested to describe the 
> behavior in RFC 4244 - it's way too long ago to remember the 
> discussion that led to the use of the term or whether anyone 
> ever raised an issue about the inconsistency before.   The 
> previous feedback for 4244bis was that we needed to be clear 
> as to how the Reason and Privacy were "captured" in the 
> History-Info header field.  If folks don't think the term 
> escape is appropriate, then what term is preferred?  I guess 
> we could just say that the Reason and Privacy header fields 
> are "added" to the hi-targeted-to-uri using the " "?" 
> mechanism" in the hi-targeted-to-uri, which is consistent 
> with the terminology used in RFC 3261.  Another thought would 
> be to include a description of "escape" as used in this 
> document in the terminology section.  
> 
> Thanks,
> Mary. 
> 
> 
> On Wed, Feb 16, 2011 at 4:48 AM, Elwell, John 
> <[email-masked]> wrote:
> 
> 
> 	We use the terms "escape", "escaped" and "escaping" 
> frequently in the draft when talking about including a 
> Privacy or Reason header field in the Headers component of a 
> SIP or SIPS URI. RFC 3261 does not use any of these terms for 
> that purpose. On the contrary, these terms are to do with 
> character representation. So I find it very confusing using 
> these terms in 4244bis when talking about placing a Privacy 
> or Reason header field in a URI.
> 	
> 	Of course, it is true that within a Privacy or Reason 
> header field within the Headers component of a SIP or SIPS 
> URI, certain characters will need escaping (as shown in 
> examples). But if we need to talk about this, we should talk 
> about character escaping - I think in the majority of cases 
> (all cases?) we are talking about the entire header field 
> where it fits within the URI (i.e., behind "?") - not 
> specifically about character representation.
> 	
> 	John
> 	
> 
> 	> Subject: Re: [sipcore] I-D 
> Action:draft-ietf-sipcore-rfc4244bis-03.txt
> 	>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 16 Feb 2011 21:14:48 +0100

Mary,

Thanks for this major rewrite and addressing very many earlier comments. I have some initial comments and also a general comment.

Comment 1: Request fails (4xx, say) and as a result a proxy retargets. According to 7.1.2, the proxy is required to include in the retargeted request all entries from received responses so far, including, presumably, entries in the 4xx response that leads to retargeting. However, if the request does not contain Supported: histinfo, there will be no entries in received responses. Therefore the final UAS will not receive a complete set of entries. So we seem to have the strange situation that the set of entries received by the UAS is dependent on support of History-Info at the UAC. This seems wrong. It seems to me that entries should always be sent backwards, subject to privacy, and perhaps not on the last hop if the UAC doesn't support it.

Comment 2: Suppose a proxy forwards a request to two targets, one with entry index 1.1 and the other with entry index 1.2. A provisional or final response is received to the first forwarded request containing an additional entry with index 1.1.1. Then a 4xx response is received to the second request, causing the proxy to retarget, this time with an entry index 1.3. According to 7.1.2 step 1, that retargeted request should contain entries 1, 1.1.1, 1.2 and 1.3. Note that 1.1 is missing. I see nothing to require the inclusion of 1.1, yet step 1 of 7.1.2 seems to require inclusion of 1.1.1. Have I misinterpreted something?

Comment 3: In 7.2 it states:
"...MUST forward captured History-Info in
   subsequent, provisional, and final responses to the request sent by
   the ultimate UAS (see Section 6.2)..."
When a proxy forwards a provisional response, how does it know that this is from the ultimate UAS? This can only be known when the first 2xx arrives. In fact the term "ultimate UAS" is also problematic because how does a proxy know that a response has come from a UAS, as opposed to a proxy?

General comment:
I found it really hard to understand how all the different procedures in sections 6, 7 and 8 fitted together, and I tried to analyse what exactly is going on. I came to the conclusion that, to a first approximation, we are trying to specify the following:

1. Procedures for receiving a request
- Cache the sequence of entries received.
- If no entry or if last entry does not match Request-URI, create one and add it to the cache.

2. Procedures for sending a request
- Include all cached entries (if any).
- Also include an entry reflecting the Request-URI of the sent request (not quite sure if this should go in the cache at this stage).
- In case of recursing, include in that new entry parameters from the Contact header field of the 3XX response.

3. Procedures for receiving a response (other than 100)
- Add to the cache any entries in the response not already in the cache.

4. Procedures for sending a response (other than 100)
- Include all cached entries.

I am sure this is an over simplification. It doesn't take account of the presence of the option tag in Supported (influences response behaviour), privacy considerations, populating the index, etc.. Also there are clearly some issues concerning exactly what a proxy includes from previous targetings when it retargets, what goes in provisional responses, and so on (impacted by the comments above, no doubt). However, I can't help feeling there might be a much simpler way of documenting all this.

John

---

From: Mary Barnes <[email-masked]>
Date: Wed, 16 Feb 2011 16:56:37 -0600

Responses inline below [MB].

On Wed, Feb 16, 2011 at 2:06 PM, Elwell, John <
[email-masked]> wrote:

> Mary,
>
> In fact what we are doing is placing these header fields in the Headers
> component of the SIP/SIPS URI - isn't that the proper way to describe it? I
> know the escape terminology has been in the draft for a long time, and if
> others are happy I guess I can live with it. Perhaps there are precedents in
> other RFCs. But I am not sure how somebody unfamiliar with this terminology
> would interpret it.
>
[MB] Yes, we are putting the header fields in the "headers" parameter  in
the SIP/SIPS URI.  So, we can change the wording to reflect such. Again, I
have no recollection of the logic behind using the term escape. We could
probably dig through the archives and see when that was introduced. In
looking at some some charts from the IETF-60 discussion of 4244 in its draft
for it is quite interesting, as one of the issues was one that you
identified [JRE-7] and the chart states that "...the Privacy header is added
to the request or escaped as part of the targeted-to-uri". I have no issue
with changing the wording as you suggest. [/MB]

>
> By the way, what if we have a tel: URI? I don't think that supports
> "escaped" header fields. Do our requirements for inserting "escaped" header
> fields apply only when the URI is SIP or SIPS?
>
[MB] Correct - the Reason and Privacy header fields can only be used for SIP
or SIPS URIs. Hadriel brought up this issue and there is text in there with
regards to this issue. [/MB]

---

From: Mary Barnes <[email-masked]>
Date: Wed, 16 Feb 2011 17:29:19 -0600

Hi John,

Thanks for the comments. Responses inline below [MB].

Mary.

On Wed, Feb 16, 2011 at 2:14 PM, Elwell, John <
[email-masked]> wrote:

> Mary,
>
> Thanks for this major rewrite and addressing very many earlier comments. I
> have some initial comments and also a general comment.
>
> Comment 1: Request fails (4xx, say) and as a result a proxy retargets.
> According to 7.1.2, the proxy is required to include in the retargeted
> request all entries from received responses so far, including, presumably,
> entries in the 4xx response that leads to retargeting. However, if the
> request does not contain Supported: histinfo, there will be no entries in
> received responses. Therefore the final UAS will not receive a complete set
> of entries. So we seem to have the strange situation that the set of entries
> received by the UAS is dependent on support of History-Info at the UAC. This
> seems wrong. It seems to me that entries should always be sent backwards,
> subject to privacy, and perhaps not on the last hop if the UAC doesn't
> support it.
>
 [MB]

>
> Comment 2: Suppose a proxy forwards a request to two targets, one with
> entry index 1.1 and the other with entry index 1.2. A provisional or final
> response is received to the first forwarded request containing an additional
> entry with index 1.1.1. Then a 4xx response is received to the second
> request, causing the proxy to retarget, this time with an entry index 1.3.
> According to 7.1.2 step 1, that retargeted request should contain entries 1,
> 1.1.1, 1.2 and 1.3. Note that 1.1 is missing. I see nothing to require the
> inclusion of 1.1, yet step 1 of 7.1.2 seems to require inclusion of 1.1.1.
> Have I misinterpreted something?
>
[MB] 1.1 should also be included. Perhaps the wording needs clarification,
but the text is attempting to state that in cases where

> When a proxy forwards a provisional response, how does it know that this is
> from the ultimate UAS? This can only be known when the first 2xx arrives. In
> fact the term "ultimate UAS" is also problematic because how does a proxy
> know that a response has come from a UAS, as opposed to a proxy?
>
[MB] It doesn't know that it's the ultimate UAS, so=o we should remove that
phrase.  It's attempting to highlight that all the information is sent in
the responses, but that's really covered elsewhere. [/MB]

>
> General comment:
> I found it really hard to understand how all the different procedures in
> sections 6, 7 and 8 fitted together, and I tried to analyse what exactly is
> going on. I came to the conclusion that, to a first approximation, we are
> trying to specify the following:
>
> - Also include an entry reflecting the Request-URI of the sent request (not
> quite sure if this should go in the cache at this stage).
> - In case of recursing, include in that new entry parameters from the
> Contact header field of the 3XX response.
>
> I am sure this is an over simplification. It doesn't take account of the
> presence of the option tag in Supported (influences response behaviour),
> privacy considerations, populating the index, etc.. Also there are clearly
> some issues concerning exactly what a proxy includes from previous
> targetings when it retargets, what goes in provisional responses, and so on
> (impacted by the comments above, no doubt). However, I can't help feeling
> there might be a much simpler way of documenting all this.
>
[MB] At this point, having worked on this document way too long, it's really
hard for me to see how to make it more clear.  It really is fairly
simple. The intent of 7.1.1 was to define the steps similar to your
simplified summary above. As far as handling the privacy, that applies to
the entirety of the hi-entries being included in an outgoing request per the
rules that we tried to highlight in the updated privacy section.  The
mechanism by which the index is calculated is referenced in the appropriate
sections and included all in one place.  I could see that we could spread
out how all the parameters are determined directly in the processing flow
and within the discussion of the specific cases, however, that isn't nearly
as modular IMHO. We did have some of it previously, but we also had
inconsistencies by doing so (and overuse of normative statements at least as
I interpreted WG feedback).   IMHO  the current form is easier from an
implementors perspective. And, the form of this document is not dramatically
unlike other RFCs, including RFC 3261 although the ABNF is earlier in the
document in 4244bis. 4244bis follows the model of describing processing for
each of the functional entities and then has sections that describe the
handling for each protocol element.  From a quick glance RFC 4028 (Session
timer) and  RFC 3325 (P-Asserted-Identity) have separate sections for Proxy
and UA behaviors, as well although the ABNF is later (but again we got
feedback that it should be earlier. It's really a chicken egg thing in my
opinion as to whether you see the protocol elements first and whether the
normative behavior for each parameter is separate from the processing flow
for the SIP entities and whether the latter is separated - i.e., we could
have a handling the request section that includes the UAC and SIP
intermediary behavior and then have a response section that includes SIP
intermediary and UAS processing.  But, again I personally feel that have the
sections separate is more useful for implementors that are in many cases
developing code for only a single functional entity.  [/MB]

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Feb 2011 08:24:09 +0100

> Sent: 16 February 2011 22:57
> To: Elwell, John
> Cc: SIPCORE
> On Wed, Feb 16, 2011 at 2:06 PM, Elwell, John 
> 	In fact what we are doing is placing these header 
> fields in the Headers component of the SIP/SIPS URI - isn't 
> that the proper way to describe it? I know the escape 
> terminology has been in the draft for a long time, and if 
> others are happy I guess I can live with it. Perhaps there 
> are precedents in other RFCs. But I am not sure how somebody 
> unfamiliar with this terminology would interpret it.
> 	
> 
> [MB] Yes, we are putting the header fields in the "headers" 
> parameter  in the SIP/SIPS URI.  So, we can change the 
> wording to reflect such. Again, I have no recollection of the 
> logic behind using the term escape. We could probably dig 
> through the archives and see when that was introduced. In 
> looking at some some charts from the IETF-60 discussion of 
> 4244 in its draft for it is quite interesting, as one of the 
> issues was one that you identified [JRE-7] and the chart 
> states that "...the Privacy header is added to the request or 
> escaped as part of the targeted-to-uri". I have no issue with 
> changing the wording as you suggest. [/MB]
[JRE] True, when I submitted earlier comments I was just going along with what appeared to be the convention. However, this time something alerted me, so I checked in RFC 3261 and found that the term "escape" was used with an entirely different meaning. I think other experts in the WG should give their opinions - I don't want to force a change if people are happy with the status quo.

> 
> 
> 	By the way, what if we have a tel: URI? I don't think 
> that supports "escaped" header fields. Do our requirements 
> for inserting "escaped" header fields apply only when the URI 
> is SIP or SIPS?
> 	
> 
> [MB] Correct - the Reason and Privacy header fields can only 
> be used for SIP or SIPS URIs. Hadriel brought up this issue 
> and there is text in there with regards to this issue. [/MB] 
[JRE] Yes, and I see now that this is kind of captured. It is a bit inconsistent, because 9.2 says you MUST escape the Reason header field - no exceptions. However, if I go back to section 5 (header field structure), I do find a statement about transforming a Tel-URI into a SIP/SIPS-URI, but that is only SHOULD strength.

John

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Feb 2011 09:20:29 +0100

Mary,

Thanks - see below:

> Sent: 16 February 2011 23:29
> To: Elwell, John
> Cc: SIPCORE
> Subject: Re: Some comments on draft-ietf-sipcore-rfc4244bis-03.txt
> 
> Hi John, 
> 
> On Wed, Feb 16, 2011 at 2:14 PM, Elwell, John 
> 	Thanks for this major rewrite and addressing very many 
> earlier comments. I have some initial comments and also a 
> general comment.
> 	
> 	Comment 1: Request fails (4xx, say) and as a result a 
> proxy retargets. According to 7.1.2, the proxy is required to 
> include in the retargeted request all entries from received 
> responses so far, including, presumably, entries in the 4xx 
> response that leads to retargeting. However, if the request 
> does not contain Supported: histinfo, there will be no 
> entries in received responses. Therefore the final UAS will 
> not receive a complete set of entries. So we seem to have the 
> strange situation that the set of entries received by the UAS 
> is dependent on support of History-Info at the UAC. This 
> seems wrong. It seems to me that entries should always be 
> sent backwards, subject to privacy, and perhaps not on the 
> last hop if the UAC doesn't support it. 
> 	
> 
>  [MB] 
> 
[JRE] Your responses seems to be lost.

> 
> 	Comment 2: Suppose a proxy forwards a request to two 
> targets, one with entry index 1.1 and the other with entry 
> index 1.2. A provisional or final response is received to the 
> first forwarded request containing an additional entry with 
> index 1.1.1. Then a 4xx response is received to the second 
> request, causing the proxy to retarget, this time with an 
> entry index 1.3. According to 7.1.2 step 1, that retargeted 
> request should contain entries 1, 1.1.1, 1.2 and 1.3. Note 
> that 1.1 is missing. I see nothing to require the inclusion 
> of 1.1, yet step 1 of 7.1.2 seems to require inclusion of 
> 1.1.1. Have I misinterpreted something?
> 	
> 
> [MB] 1.1 should also be included. Perhaps the wording needs 
> clarification, but the text is attempting to state that in 
> cases where  
[JRE] Your responses seems to have been truncated.

> 	When a proxy forwards a provisional response, how does 
> it know that this is from the ultimate UAS? This can only be 
> known when the first 2xx arrives. In fact the term "ultimate 
> UAS" is also problematic because how does a proxy know that a 
> response has come from a UAS, as opposed to a proxy?
> 	
> 
> [MB] It doesn't know that it's the ultimate UAS, so=o we 
> should remove that phrase.  It's attempting to highlight that 
> all the information is sent in the responses, but that's 
> really covered elsewhere. [/MB]
[JRE] It does seem to make sense to simplify it so that you send all information in all provisional or final responses (except 100). Just an example to help confirm whether this simple rule makes sense:
A proxy forks, sending requests with indices 1.1, 1.2 and 1.3. Then the 1.3 branch sends a response (provisional, final) containing additional entry 1.3.1. In this case the response that the proxy sends upstream would contain 1, 1.1, 1.2, 1.3 and 1.3.1 - correct? So even though the 1.1 and 1.2 branches have not responded, they are included in the upstream response?

> 
> 
> 	General comment:
> 	I found it really hard to understand how all the 
> different procedures in sections 6, 7 and 8 fitted together, 
> and I tried to analyse what exactly is going on. I came to 
> the conclusion that, to a first approximation, we are trying 
> to specify the following:
> 	
> 	- If no entry or if last entry does not match 
> Request-URI, create one and add it to the cache.
> 	
> 	- Also include an entry reflecting the Request-URI of 
> the sent request (not quite sure if this should go in the 
> cache at this stage).
> 	- In case of recursing, include in that new entry 
> parameters from the Contact header field of the 3XX response.
> 	
> 	I am sure this is an over simplification. It doesn't 
> take account of the presence of the option tag in Supported 
> (influences response behaviour), privacy considerations, 
> populating the index, etc.. Also there are clearly some 
> issues concerning exactly what a proxy includes from previous 
> targetings when it retargets, what goes in provisional 
> responses, and so on (impacted by the comments above, no 
> doubt). However, I can't help feeling there might be a much 
> simpler way of documenting all this.
> 	
> 
> [MB] At this point, having worked on this document way too 
> long, it's really hard for me to see how to make it more 
> clear.  It really is fairly simple. The intent of 7.1.1 was 
> to define the steps similar to your simplified summary above. 
[JRE] That is not how I see it. 7.1 only deals with requests, not responses, and 7.1 only deals with proxy/intermediary, not UAC, UAS, redirect server. I was trying to pull all these together into one set of procedures that is common to all (except obviously steps relating to receiving a request and sending a response will not apply to a UAC and steps relating to sending a request and receiving a response will not apply to a UAS or redirect server (or a proxy that rejects). In other words, I was trying to pull together sections 6, 7 and 8 into a single section covering everything. This is because procedures for receiving request, for example, are similar no matter which entity is involved.

> As far as handling the privacy, that applies to the entirety 
> of the hi-entries being included in an outgoing request per 
> the rules that we tried to highlight in the updated privacy 
> section.  The mechanism by which the index is calculated is 
> referenced in the appropriate sections and included all in 
> one place.  I could see that we could spread out how all the 
> parameters are determined directly in the processing flow and 
> within the discussion of the specific cases, however, that 
> isn't nearly as modular IMHO. We did have some of it 
> previously, but we also had inconsistencies by doing so (and 
> overuse of normative statements at least as I interpreted WG 
> feedback). 
[JRE] I am quite happy with common procedures like privacy, Reason header field and indexing to be kept separate, as we already have in section 9. My comments referred to sections 6, 7 and 8, and even if we decide to restructure these, we can still refer out to section 9 for the common bits.

> IMHO  the current form is easier from an 
> implementors perspective. And, the form of this document is 
> not dramatically unlike other RFCs, including RFC 3261 
> although the ABNF is earlier in the document in 4244bis. 
> 4244bis follows the model of describing processing for each 
> of the functional entities and then has sections that 
> describe the handling for each protocol element.  From a 
> quick glance RFC 4028 (Session timer) and  RFC 3325 
> (P-Asserted-Identity) have separate sections for Proxy and UA 
> behaviors, as well although the ABNF is later (but again we 
> got feedback that it should be earlier. It's really a chicken 
> egg thing in my opinion as to whether you see the protocol 
> elements first and whether the normative behavior for each 
> parameter is separate from the processing flow for the SIP 
> entities and whether the latter is separated - i.e., we could 
> have a handling the request section that includes the UAC and 
> SIP intermediary behavior and then have a response section 
> that includes SIP intermediary and UAS processing.  But, 
> again I personally feel that have the sections separate is 
> more useful for implementors that are in many cases 
[JRE] Putting aside for the moment the question of whether to restructure sections 6, 7 and 8, I would like to try to refine the simplified model I proposed to get a common understanding of what we are trying to achieve. A commonly understood model would help me to review the existing text to ensure that it is consistent with the model. At present I am finding it difficult to understand the text. Perhaps that is my fault, not having put enough time into it, but I would appreciate assistance from the WG in trying to get a better understanding. So here again is the model as I see it (slightly changed from before):

2. Procedures for sending a request
- Generate an additional entry reflecting the Request-URI of the sent request, and add this to the cache.
- In case of recursing, include in that new entry parameters from the Contact header field of the 3XX response.
- Include all cached entries.

3. Procedures for receiving a response (other than 100)
- Add to the cache any entries in the response not already in the cache.
- In the case of a 3xx/4xx/5xx/6xx response, add a Reason header field to the cached entry that was generated for the corresponding request.

All of the above subject to common rules relating to privacy, histinfo option tag, and indices.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Feb 2011 08:53:44 -0500

I think the use of "escaped" in the sense used in 4244bis has become 
informal colloquial usage, and I am probably as guilty of using it as 
anyone. But I agree it is problematic as formal language in a normative 
document. IMO the wording changes offered by John are an improvement.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Wed, 23 Feb 2011 14:29:49 +0100

Hello,

Comment 1:
I have a first comment about the Tel URI question. 
By definition it is not possible to have de telURI in History-Info :
hi-targeted-to-uri = name-addr
And per RFC3261
name-addr      =  [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec      =  SIP-URI / SIPS-URI / absoluteURI
A simple note could be used as a remider.

Comment 2:
About the "escaped" term, I found the following statements in RFC3261 and RFC2396. 
I conclude that a correct terminology for including Privacy and Reason headers in the hi-targeted-to-uri could be: 
Privacy and Reason Header fields can be present in the hi-targeted-to-URI parameter as URI "headers" component described in RFC3261. They MUST be present in an "escaped" form as stated in RFC2396. 

In RFC 2396:
  "A URI is always in an "escaped" form, since escaping or unescaping a completed URI might change its semantics."

  "An escaped octet is encoded as a character triplet, consisting of the percent character "%" followed by the two hexadecimal digits representing the octet code."

In RFC 3261:
"sip:user:password@host:port;uri-parameters?headers"

"Note, however, that any characters allowed there that are not allowed in the user part of the SIP URI MUST be escaped."

"Headers fields in the SIP request can be specified with the "?" mechanism within a URI. The header names and values are encoded in ampersand separated hname = hvalue pairs."

headers         =  "?" header *( "&" header )
header          =  hname "=" hvalue
hname           =  1*( hnv-unreserved / unreserved / escaped )
hvalue          =  *( hnv-unreserved / unreserved / escaped )
hnv-unreserved  =  "[" / "]" / "/" / "?" / ":" / "+" / "$"
unreserved  =  alphanum / mark
escaped     =  "%" HEXDIG HEXDIG

Best Regards,
Marianne

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Paul Kyzivat
> Envoyé : jeudi 17 février 2011 14:54
> À : [email-masked]
> Objet : Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt
> 
> I think the use of "escaped" in the sense used in 4244bis has 
> become informal colloquial usage, and I am probably as guilty 
> of using it as anyone. But I agree it is problematic as 
> formal language in a normative document. IMO the wording 
> changes offered by John are an improvement.
> 
> 	Thanks,
> 	Paul
> 
> >> 	In fact what we are doing is placing these header fields in the 
> >> Headers component of the SIP/SIPS URI - isn't that the 
> proper way to 
> >> describe it? I know the escape terminology has been in the 
> draft for 
> >> a long time, and if others are happy I guess I can live with it. 
> >> Perhaps there are precedents in other RFCs. But I am not sure how 
> >> somebody unfamiliar with this terminology would interpret it.
> >> 	
> >>
> >> parameter  in the SIP/SIPS URI.  So, we can change the wording to 
> >> reflect such. Again, I have no recollection of the logic 
> behind using 
> >> the term escape. We could probably dig through the 
> archives and see 
> >> when that was introduced. In looking at some some charts from the 
> >> IETF-60 discussion of
> >> 4244 in its draft for it is quite interesting, as one of 
> the issues 
> >> was one that you identified [JRE-7] and the chart states 
> that "...the 
> >> Privacy header is added to the request or escaped as part of the 
> >> targeted-to-uri". I have no issue with changing the wording as you 
> >> suggest. [/MB]
> > [JRE] True, when I submitted earlier comments I was just 
> going along with what appeared to be the convention. However, 
> this time something alerted me, so I checked in RFC 3261 and 
> found that the term "escape" was used with an entirely 
> different meaning. I think other experts in the WG should 
> give their opinions - I don't want to force a change if 
> people are happy with the status quo.
> >
> >>
> >>
> that supports 
> >> "escaped" header fields. Do our requirements for inserting 
> "escaped" 
> >> header fields apply only when the URI is SIP or SIPS?
> >> 	
> >>
> >> [MB] Correct - the Reason and Privacy header fields can 
> only be used 
> >> for SIP or SIPS URIs. Hadriel brought up this issue and 
> there is text 
> >> in there with regards to this issue. [/MB]
> > [JRE] Yes, and I see now that this is kind of captured. It 
> is a bit inconsistent, because 9.2 says you MUST escape the 
> Reason header field - no exceptions. However, if I go back to 
> section 5 (header field structure), I do find a statement 
> about transforming a Tel-URI into a SIP/SIPS-URI, but that is 
> only SHOULD strength.
> >
> > John

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Feb 2011 09:02:42 -0500

marianne,

(as individual)

> addr-spec      =  SIP-URI / SIPS-URI / absoluteURI

In the above, a tel: URI matches absoluteURI.

Its exactly this same rule that permits tel: URIs in From/To headers.
Anything allowed in From/To is allowed in H-I. That also includes pres:.

Of course, absoluteURI also permits some things that *may* be nonsense 
for H-I, such has http:.

(OTOH, URIs such as http: that can't be used as targets of sip requests 
MAY appear as Contacts in a 3xx. So maybe there is some way they could 
end up in H-I.)

	Thanks,
	Paul

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Wed, 23 Feb 2011 15:25:32 +0100

Ok thanks Paul for this clarification.

> De : Paul Kyzivat [mailto:[email-masked]] 
> Envoyé : mercredi 23 février 2011 15:03
> À : MOHALI Marianne RD-CORE-ISS
> Cc : [email-masked]; [email-masked]; 
> [email-masked]
> Of course, absoluteURI also permits some things that *may* be 
> nonsense for H-I, such has http:.
> 
> (OTOH, URIs such as http: that can't be used as targets of 
> sip requests MAY appear as Contacts in a 3xx. So maybe there 
> is some way they could end up in H-I.)
> 
> 	Thanks,
> 	Paul
> 
> 	Thanks,
> 	Paul
>

---

From: <[email-masked]>
Date: Mon, 28 Feb 2011 10:59:25 +0100

Hi Mary,

In the draft, there is a mistake in the Reason syntax used.
The Reason header is written with a "=" instead of a ":" (HCOLON) after the header name, as defined in RFC3326. 

Regards,
Marianne

________________________________

	De : [email-masked] [mailto:[email-masked]] De la part de Mary Barnes
	Envoyé : lundi 14 février 2011 16:42
	À : SIPCORE
	Objet : Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt

	The changes are quite extensive based on all the feedback and include the following: 
	1) Lots of editorial:
	a) Reorganized sections similar to the RFC 4244 order - i.e., introduce header field parameters and syntax first, then describe how the functional entities use the header.  This removes redundant  (and often inconsistent) text describing the parameters.
	b) Expanded use of "header" to "header field"
	c) More precision in terms of "escaping" of the Privacy and Reason headers in the hi-targeted-to-uri (versus "adding"/"setting"/etc. them to the hi-entry).
	d) Consistent use of parameter names (i.e., hi-entry versus entry, hi-target versus target, etc.)
	e) Moved item 6 in the Index section to the section on Response handling
	f) Removed last remaining vestiges of inline references to requirements.

	2) Clarifications of functionality/applicability including:
	a)  which messages may contain History-Info
	b)  removing security text with regards to being able to figure out if there are missing entries when using TLS (issue #44)
	c) More complete information on the new header field parameters as they relate to the hi-target parameter.  
	d) Changed wording from passive to active for normative statements in many cases and removed superfluous normative language. 

	3) Rewrite of the Privacy section to address issues and splitting into the setting of the Privacy header fields and the processing/application of the privacy header field priv-values. 

	4) Rewrite of the Reason header field section - simplifying the text and adding back the RFC 4244 text with regards to the use of the Reason header field in cases of internal retargeting. 

	I did attempt to cover all the comments, but since alot of the relevant text changed, it's possible that I missed some comments.   However, we're hoping that folks will find this version to be easier to follow. 

	Regards,
	Mary.

---

From: Brett Tate <[email-masked]>
Date: Mon, 28 Feb 2011 03:00:18 -0800

The use of "=" (instead of ":") is correct for embedding headers in a SIP-URI.  The following is the "headers" ABNF from RFC 3261.

SIP-URI =  "sip:" [ userinfo ] hostport uri-parameters [ headers ]
headers =  "?" header *( "&" header )
header  =  hname "=" hvalue

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Monday, February 28, 2011 4:59 AM
> To: [email-masked]; [email-masked]
> Subject: [sipcore] Reason syntax error in draft-ietf-sipcore-
> rfc4244bis-03
> 
> Hi Mary,
>

---

From: <[email-masked]>
Date: Mon, 28 Feb 2011 15:32:28 +0100

Hi Brett,

I saw this text but I though that the header's syntax had precedence.
Thank you !

Marianne 

> De : Brett Tate [mailto:[email-masked]] 
> Envoyé : lundi 28 février 2011 12:00
> Cc : [email-masked]
> Objet : RE: [sipcore] Reason syntax error in 
> draft-ietf-sipcore-rfc4244bis-03
> 
> The use of "=" (instead of ":") is correct for embedding 
> headers in a SIP-URI.  The following is the "headers" ABNF 
> from RFC 3261.
> 
> SIP-URI =  "sip:" [ userinfo ] hostport uri-parameters [ 
> headers ] headers =  "?" header *( "&" header ) header  =  
> hname "=" hvalue
> 
> > The Reason header is written with a "=" instead of a ":" (HCOLON) 
> > after the header name, as defined in RFC3326.
> > 
> > Regards,
> > Marianne
> 
>