Subject: [sipcore] I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt

From: [email-masked]
Date: Tue, 15 Mar 2011 11:30:01 -0700

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-04.txt
    Pages         : 32
    Date          : 2011-03-15
    
   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-04.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: Tue, 15 Mar 2011 13:46:18 -0500

Hi folks,

I have updated the document to incorporate the feedback on the -03 as
follows:

1) The biggest change was the reformating  inline with John's suggestion:
http://www.ietf.org/mail-archive/web/sipcore/current/msg04010.html
It is not verbatim, but rather I included some of the past text in the
relevant sections and I included a bullet list in some cases rather than
just a paragraph as that was one of the formatting changes we made between
RFC4244 and 4244bis in that the text in paragraph form can be rather dense.
 I believe the spirit and intent of John's proposal has been accomodated (I
don't know that as many words were saved). Also, I just noticed some of the
bullet lists don't have the "o" - I'll have to fix that.  I think one of the
most important aspects of John's proposal was introducing the "caching" of
the hi-entries as that wasn't clearly spelled out previously and that really
did help to clarify the processing.  I do think the breakdown in the
sending/receiving of the request and sending/receiving of a response into
common processing is quite helpful.

2) Removed the term "escape" with regards to the Privacy and Reason header
fields and just stated that those header fields were included in the
hi-targeted-to-uri.  I think this also improves readbility.

3) Additional clarification around the Tel-URI.

I think the doc should be ready for another WGLC.

Thanks,
Mary.

---------- Forwarded message ----------
From: <[email-masked]>
Date: Tue, Mar 15, 2011 at 1:30 PM
Subject: I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt
To: [email-masked]
Cc: [email-masked]

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-04.txt
   Pages         : 32
   Date          : 2011-03-15

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 16 Mar 2011 22:44:12 +0100

Mary,

Thanks for adopting the principles I proposed. Although I agree with much of the minor rewording you carried out, I do have some issues as follows. Also I still need to comment on other parts of the document - these comments apply to sections 6 to 9 only.

1. Section 6:
"forward hi-entries received in requests at the UAS to the request 
   being forwarded by the UAC"
Change "the request" to "requests".

2. Section 6:
"carrying forward responses 
   received"
Change to "carrying forward hi-entries in responses received"

3. Section 6.1:
"The UAC MUST include the "histinfo" option tag in the Supported
   header"
Change "header" to "header field".

4. Section 6.1:
"Note
   that in the case of an initial request , there is no cache of hi-
   entries with which to populate the History-info header field..."
We should also observe that when a UAC is part of a B2BUA, the cache might not be empty (I failed to cover this in my proposed text). I suggest:
"Note that in the case of an initial request, except where the UAC is part of a B2BUA, there is no cache of hi-
   entries with which to populate the History-info header field..."

5. Section 6.1:
"as
   described in  and the hi-index is set to 1 per Section 10.3."
The words "as described in" should be deleted.

6. Section 7: In my opinion it would be more logical to list the 4 cases in order of the sections they reference (9.1, 9.2, 9.3, 9.4), as I proposed.

7. Section 7:
"For each outgoing request relating to a target in the target set,
      the intermediary MUST add an hi-entry for the specific target, per
      the procedures in Section 9.2."
This is wrong. ALL the procedures of 9.2 apply, not just the one about adding an hi-entry for the specific target. Just say "...MUST follow the procedures of Section 9.2" - don't try to repeat things from the referenced section.

8. Section 7:
"for for"

9. Section 7:
"An intermediary MUST follow the procedures of Section 9.3 when a
      SIP response containing hi-entries  is received."
The procedures of 9.3 cover ALL SIP responses, whether or not they contain hi-entries. For example,  if the UAS does not support H-I, it will not send back any hi-entries, but the procedures of 9.3 still apply to the intermediary that receives such a response. Delete "containing hi-entries"

10. Section 9:
"This section describes the procedures for SIP entities for the
   handling of SIP requests and responses containing the History-Info
   header fields."
I think it would be better to say
"This section describes the procedures for SIP entities for the handling of the History-Info header field in SIP requests and responses".
My reasoning is that not all received requests and responses contain the header field, but there are still procedures that apply to such requests and responses, perhaps leading to the inclusion of the header field in forwarded requests/responses. So saying "SIP requests and responses containing the History-Info header fields" doesn't seem quite right.

11. "9.1.  Receiving a Request with History-Info "
Delete "with History-Info". The procedures cover all requests, even if received with no H-I.

12. Section 9.1:
"The SIP entity MUST set the hi-index parameter to a value of "1" ,
      as described in Section 10.3."
Delete 'to a value of "1"'. This is not always true, if there are hi-entries from upstream entities, but the hi-entry from the last entity is missing and needs to be added.

13. Section 9.2:
"MUST add a new
   hi-entry to the outgoing request"
Just to be clear, it might be worth saying:
"MUST add a new
   hi-entry to the outgoing request (but not the cache)"

14. Section 9.2:
"populating the header field  as
   follows:"
I think this should say:
"populating the hi-entry as follows:"

15. Section 9.2:
"The SIP entity MUST include an "rc" or "mp" header field parameter
      in the hi-entry, if applicable, per the procedures in
      Section 10.4."
The following text that I proposed before seems to be missing:
"If the sent request is a direct result of retargeting to a contact URI received in a 3xx response and the Contact header field in that response contained an "rc" or "mp" header field parameter, the entity MUST include the corresponding parameter in the new hi-entry in accordance with 10.4."
(although I am not certain the words "in accordance with 10.4 are needed - in retrospect I would delete those words)

16. Section 9.3:
"e.g., 1.2.1 comes after 1.2 but
      before 1.3 )"
Just to be even clearer, I would suggest:
"e.g., 1.2.1 comes after 1.2 but
      before 1.2.2 or 1.3 )"

17. Section 9.3:
"The SIP entity then MUST add a  Reason header field"
I think this should say:
"The SIP entity then MUST add one or more Reason header fields"
This is because, according to 10.2, more than one can be added in some cases.

18. Section 9.4:
"When sending a response other than a 100, a SIP entity MUST include
   all the cached hi-entries in the response  with the following
   exception: If the received request contained no hi-entries and there
   is no "histinfo" option tag in the Supported header field, the SIP
   entity MUST NOT include hi-entries in the response.  In the former
   case , the privacy procedures as described in Section 10.1.2 MUST be
   followed."
I find the words "In the former case" a little confusing. Also, if there are exceptions to the normative statement in the first sentence, they should probably be made clear in that first sentence. I would propose:
"When sending a response other than a 100, a SIP entity MUST include
   all the cached hi-entries in the response, subject to the privacy considerations in Section 10.1.2 and with the following
   exception: If the received request contained no hi-entries and there
   is no "histinfo" option tag in the Supported header field, the SIP
   entity MUST NOT include hi-entries in the response."

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mary Barnes
> Sent: 15 March 2011 18:46
> To: SIPCORE
> Subject: [sipcore] Fwd: I-D 
> ACTION:draft-ietf-sipcore-rfc4244bis-04.txt
> 
> Hi folks, 
> 
> I have updated the document to incorporate the feedback on 
> the -03 as follows:
> 
> It is not verbatim, but rather I included some of the past 
> text in the relevant sections and I included a bullet list in 
> some cases rather than just a paragraph as that was one of 
> the formatting changes we made between RFC4244 and 4244bis in 
> that the text in paragraph form can be rather dense.  I 
> believe the spirit and intent of John's proposal has been 
> accomodated (I don't know that as many words were saved). 
> Also, I just noticed some of the bullet lists don't have the 
> "o" - I'll have to fix that.  I think one of the most 
> important aspects of John's proposal was introducing the 
> "caching" of the hi-entries as that wasn't clearly spelled 
> out previously and that really did help to clarify the 
> processing.  I do think the breakdown in the 
> sending/receiving of the request and sending/receiving of a 
> response into common processing is quite helpful. 
> 
> 2) Removed the term "escape" with regards to the Privacy and 
> Reason header fields and just stated that those header fields 
> were included in the hi-targeted-to-uri.  I think this also 
> improves readbility.  
> 
>    Title         : An Extension to the Session Initiation 
> Protocol (SIP) for Request History Information
> Internet-Draft 
> <https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Dr
> aft>  directories: http://www.ietf.org/shadow.html

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 25 Mar 2011 15:46:59 +0100

Mary,

I already sent you my comments on sections 6 to 9. Now I finally got round to reading much of the rest of the document (up to section 12). Sorry, my energy ran out after that - I will leave it to others to check the rest. I have to say that these sections are not yet ready to go - quite a few inaccuracies and inconsistent use of terminology. Here goes:

1. Section 1:
"Many services that SIP is anticipated to support require the ability
   to determine why and how a SIP requests arrived at a specific
   application."
Change "requests" to "request".

2. Section 5:
"By adding the new
      entries in order (i.e., following existing entries per the details
      in Section 10.3), including the index and securing the header, the
      ordering of the History-info header fields in the request is
      assured."
What is meant by "securing the header"? Why just the header and not the body? Surely the only means we are suggesting is TLS, which secures the body as well as the header.

3. Section 5:
"hi-target-param: An optional parameter reflecting the mechanism by
      which the Request URI captured in the hi-targeted-to-uri in the
      hi-entry was determined."
The term "hi-entry" has not been introduced yet.

4. Section 5:
""rc": The hi-targeted-to-URI is a contact for the Request-URI,
         in the incoming request, that is bound to an AOR in an abstract
         location service."
What is bound? Presumably the contact, not the Request-URI, and not the request. Wording is ambiguous, because "that is bound" is too separated from "contact". Also "Request-URI is ambiguous - the Request-URI before or after retargeting. I think it should say something like "...is a contact bound to an AOR in an abstract location service, that AOR being the Request-URI that was retargeted."

5. Section 5:
"This occurs when a request is to
         statically or dynamically retargeted "
Delete "to".

6. Section 5:
"The
         value of the index in the "mp" header field parameter
         represents the value of the hi-index in the hi-entry with an
         hi-targeted-to- uri that reflects the Request-URI that was
         retargeted, thus identifying the "mapped from" target."
What is meant by "the value of the index" at the start of the sentence? Isn't this simply the value of the "mp" parameter? In any case, shouldn't we use a similar formulation to that used in the corresponding sentence in the definition of "rc"?

7. Section 5:
"hi-param = hi-index / hi-target / hi-extension"
There is no definition of hi-target - I think it should be "hi-target-param". However, there are other places in the document where "hi-target" is referred to. I think hi-target-param is better - please align all instances.

8. Section5:
"addition to the parameters defined by the ABNF, an hi-entry may
   also include a Reason header field and a Privacy header field"
I think it should say "...and/or a Privacy header field. We can have one without the other.

9. Section 5:
"which
   are both included in the hi-targeted-to-uri as described below:"
To make it clear where in the hi-targeted-to-uri, I think it should say "...included in the "headers" component of the hi-targeted-to-uri".

10. Section 5:
"A reason is
      included for the hi-targeted-to-uri that was retargeted as opposed
      to the hi-targeted-to-uri to which it was retargeted."
Ambiguous. Does it mean it appears in the hi-entry for that URI, or does it mean it relates to that URI even though it appears in the URI resulting from retargeting? In addition, a reason can be included (and will appear in the response) even if there is no retargeting as a result of that reason. I would suggest: "A reason is included in the hi-targeted-to-uri of an hi-entry to reflect information received in a response to the request sent to that URI."

11. Section 5.1:
"and
   the headers in the URI are not shown properly formatted for escaping."
I am not sure what this is talking about - if it is talking about "headers" component in a URI, I don't see any in the example. Delete this part of the sentence?

12. Section 10.1:
"Section 10.1.1 describes the use of the Privacy header
   field defined in [RFC3323] to indicate the privacy to be applied to
   the History-Info header field entries."
I think 10.1.1 only describes insertion - it doesn't describe use on receipt. Change "the use of" to "the insertion of".

13. Section 10.1:
"Section 10.1.2 describes the
   processing of the priv-values in the Privacy header field to privacy
   protect the History-Info header field entries in the request or
   response that is being forwarded."
I think this would be clearer if it said "Section 10.1.2 describes how to apply privacy to a request or response that is being forwarded, based on the presence of the Privacy header field."

14. Section 10.1.1:
"The Privacy header field is
   used by the UAC to indicate the privacy to be applied to all the hi-
   entries in the request as follows:"
This seems to suggest it is used to indicate whether privacy is to be applied or not, but the bullets below are specific to the case where privacy IS to be applied. I would suggest "...to indicate that privacy is to be applied"

15. Section 10.1.1:
"for each hi-entry added by intermediary, as the request is
   retargeted within the domain for which the SIP entity is responsible."
Does "each hi-entry added by intermediary" include any hi-entries that have been received in responses from downstream entities, these hi-entries then being added to any additional branches?

16. Section 10.1.2:
"When a request is retargeted to a URI associated with a domain for
   which the SIP intermediary is not responsible or a response is
   forwarded"
I think the words "to ... a domain for which the SIP intermediary is not responsible" applies also when forwarding a response. Should it say:
"When a request is retargeted to a URI associated with a domain for
   which the SIP intermediary is not responsible or a response is
   forwarded to a domain for which the SIP intermediary is not responsible"

17. In the same sentence:
"a Privacy Service at the boundary of the domain applies"
Where is "Privacy Service" defined (for priv-value "history")? Presumably the following paragraphs specify the Privacy Service, but this is not clear.

18. In the same sentence:
"at the boundary of the domain"
How do we ensure the presence of a Privacy Service at a domain boundary? For example, a proxy inserts an hi-entry marked with privacy and sends it to the next node in its domain. But that node doesn't support H-I, so just passes H-I on transparently, perhaps outside the domain. There needs to be an element of trust here, similar to RFC 3325, where information subject to privacy is sent only to trusted entities within the domain, but furthermore, to be trusted an entity needs to support H-I. See also my last comment (on section 12).

19. Section 10.1.2:
"If there is a Privacy header field in the request with a priv-value
   of "header" or "history","
I think this is talking about a Privacy header field in the message header, as opposed to a Privacy header field in the "headers" component of an hi-targeted-to-uri. This should be made clear, although there is no obvious terminology we can call on. Perhaps:
"If there is a Privacy header field in the request, other than in the "headers" component of an hi-targeted-to-uri, with a priv-value
   of "header" or "history","

20. The same quoted text talks about requests, but don't we need similar procedures for responses?

21. In the same sentence:
"then the hi-targeted-to-uris in the hi-
   entries, associated with the domain for which a SIP intermediary is
   responsible, are anonymized."
I think this is trying to say "a SIP intermediary  anonymizes any hi-targeted-to-uris associated with its own domain". But I am rather confused that this sentence talks about "a SIP intermediary" and the next sentence, which seems to repeat things in normative language, talks about "The Privacy Service". We could do with some rationalization of the two sentences.

22. Section 10.1.2:
"If there is not a Privacy header field in the request or response
   that is being forwarded"
Again I think we need to qualify this by adding "other than in the "headers" component of an hi-targeted-to-uri".

23. Concerning the same sentence, again I have trouble with this sentence and the next sentence covering essentially the same thing with different terminology.

24. Section 10.2:
"If the retargeting is due to receipt of an explicit SIP response and
   the response contains any Reason header fields (see [RFC3326]), then
   the SIP entity MUST include the Reason header fields in the hi-
   targeted-to-uri containing the URI of the request that was
   retargeted"
According to 9.3 step 2, we add Reason to the cached hi-entries, and independently of whether the request then gets retargeted. I think it should say something like:  "To add Reason header fields to a cached hi-entry as a result of receiving a response to the request sent to the hi-entry's hi-targeted-to-uri, a SIP entity MUST use any Reason header fields received in the response"

25. Section 10.2:
"MUST
   include a Reason header field, containing the SIP Response Code"
What if it is a 2xx response - does this make sense?

26. In the same sentence:
"that
   triggered the retargeting, in the hi-targeted-to-uri containing the
   URI of the request that was retargeted"
Delete these words, because it gets added to the cached hi-entry independently of whether it is then retargeted.

27. Section 10.2:
"containing a SIP
   error response code of 408 "Request Timeout" in hi-targeted-to-uri
   containing the URI of the request that was retargeted. "
Again, delete "in hi-targeted-to-uri
   containing the URI of the request that was retargeted. "
because we are just talking about adding to the cache.

28. Section 10.2:
"The SIP
   entity MAY also include a Reason header field in the hi-targeted-to-
   uri containing the URI of the request that was retargeted as a result
   of internal retargeting."
Change "the request" to "a request".

29. Section 10.2:
"If additional Reason headers are defined in the future "
Does this mean "additional protocol values"? However, no specific protocol values are mentioned above, so why to we need to mention "additional" protocol values?

30. Section 10.3:
"Basic Forwarding: "
What is "Basic Forwarding"?

31. Section 10.3, item 1:
"In the case of a request that is being
       forwarded"
Any request can be forwarded eventually, even it has been retargeted, redirected, etc.. So how exactly does this case 1 differ from some of the other cases?

32. Also in item 1:
"MUST
       add another level of indexing by appending the dot delimiter
       followed by an initial hi-index for the new level of 1."
The new level is not, in general, level 1. I think this should say "An initial value of 1 for the new level." Unfortunately the ABNF fails to give a name to a single component of hi-index, so I have just called it "value".

33. "a proxy would add an hi-entry with
       an hi-index to 1.1.1 "
Change "to" to "of".

34. In item 3:
"Retargeting within a processing entity - subsequent instance: For
       each subsequent retargeting of a request by the same SIP entity,
       the SIP entity MUST add another branch."
What exactly is "another branch"? RFC 3261 already talks about creating branches, so why do we need a normative statement here to tell us to do something that is normatively specified in RFC 3261? We should only be making normative statements that are specific to H-I.

35. Also in item 3:
"The SIP entity MUST
       calculate the hi-index for each new branch by incrementing the
       value from the hi-index in the last hi-entry at the current
       level."
It is unclear what "value" means. I think it is the value of the rightmost level.

36. In item 4:
"That is, the lowest/last
       digit of the hi-index MUST be incremented"
Since a value for a particular level within hi-index can comprise more than one digit, the word "digit" here is not correct. It is the integer that should be incremented.

37. In the same sentence:
"MUST be incremented (i.e., a new branch is
       created), with the increment of 1"
I think "with the increment of 1" can be deleted.

38. In item 5:
"Note that for each individual fork, only the
       hi-entry corresponding to that fork is included (e.g., the hi-
       entry for fork 1.1.1 is not included in the request sent to fork
       1.1.2, and vice-versa)."
I don't think this is true. For example, I receive hi-entry 1.2, I fork first of all with hi-entry 1.2.1. This receives a response 4xx, so I then fork again, this time with hi-entry 1.2.2. I thought in this case hi-entry 1.2.1, as well as 1.2.2,  would be included in the new forwarded request (since 1.2.1 will be in the cache at this stage).

39. "10.4.  Mechanism for Target Determination in the History-Info Header
       Field"
Wrong title - the section is to do with indicating how the target was determined, not with the determination mechanism itself. Perhaps "10.4 Indicating the mechanism by which the target was determined..."

40. Section 10.4:
"   This specification defines two header field parameters, "rc" and
   "mp", indicating two non-inclusive mechanisms by which a new target
   for a request is determined."
I am not sure what "non-inclusive" means here.

41. Section 10.4:
"in the case of 3xx responses"
I think this should say "in the case of retargeting to a contact URI received in a 3xx response".

42. Section 10.4:
"If the Contact header field
   does not contain an "rc" or "mp" header field parameter, then the SIP
   entity MUST NOT include an "rc" or "mp" in the hi-entry when the
   request is retargeted."
I think this sentence is still talking about the 3xx case, but it is not clear. Should say:
"....when the request is retargeted to a contact URI received in a 3xx response".

43. Section 10.4:
""rc": The target was determined based on a contact that is bound
      to an AOR in an abstract location service for the Request-URI
      being retargeted."
This doesn't make it clear that the Request-URI is the AOR. However, for both this and the "mp" bullet point, we should perhaps refer to section 5, where those are defined, rather than reproducing the definition here with the risk of it being different.

44. Section 10.4:
"The mapping was done due to receiving a 3xx response, in which
      case the mp-value is an earlier sibling of the hi-entry's index,
      that of the downstream request which received the 3xx response."
I don't think this is right, since the issuer of the 3xx will build the rc or mp parameter, and therefore it will reference the index received by that entity. This could indeed be a sibling, but it could also be a child of a sibling, a child of a child of a sibling, and so on.

45. Section 11:
"Thus, if gaps are detected,
   the SIP entity MUST NOT treat this as an error, but rather indicate
   to any applications that there are gaps."
I think changing "rather indicate" to "MUST indicate" would be clearer, if we do indeed intend it normatively.

46. Section 11:
"The most complete
   information available to the application is the History-Info entries
   starting with the last hi-entry with an index of "1"."
This is not true. The most complete is the complete set of hi-entries. Even if there are gaps, the information subsequent to the last gap will not be as complete as the total information.

47. Section 11:
"The following summarizes the categories of  information that
   applications can use:"
I thinks these are only examples, rather than a summary of everything an application could used. Change "summarizes" to "examples".

48. Section 11, item 2:
"the index that matches the value of  the last hi-
       entry with ..."
An index cannot match an entire hi-entry. I think this should say "the index that matches the value of the "rc" parameter in the last hi-
       entry with ..."
A similar correction should be applied to items 3, 4 and 5 too.

49. Section 11, item 2:
"rc" header parameter"
I am not sure that "header parameter" is the right way to describe "rc". It might be more accurate to say "hi-entry parameter" or, to use the ABNF name, "hi-target-parameter", or simply "parameter". Whatever is chosen, it needs to be consistent throughout the document.
A similar correction should be applied to items 3, 4 and 5 too.

50. Section 11, item 2:
"i.e., the Request URI associated with the destination of
       the request was determined based on an AOR-to-contact binding in
       an abstract location service."
This is confusing, because the Request-URI changes during retargeting, and it is not clear to which Request-URI and to which request we refer. Perhaps it means the final target, but that is not necessarily true - I am sure there must be some corner cases where there is a non-"rc" retarget after the last "rc" retarget. I think all we can say for certain is something like: "i.e., the last AOR that was retargeted to a contact based on an AOR-to-contact binding in an abstract location service." Note that a formulation like this would better match the style of the formulation in item 3.

51. Section 11, item 4:
"thus the
       first hi-entry with an "rc" header parameter  within the domain
       associated with the target URI at the destination is more likely
       to be useful."
I think this should say:
"thus the hi-entry that matches the value of the "rc" parameter of the first hi-entry with an "rc" parameter within the domain..."
A similar correction should be applied to item 5 too.

52. Section 11:
"hi-entry who  index "
Change to:
"hi-entry whose  index "

53. Section 11:
"matches the index  of the first"
I think this should say:
"matches value of the "mp" parameter of the first"

54. Section 11:
"History-Info entry"
Why not "hi-entry" as elsewhere?
Similarly "History-Info entries" later in sentence.

55. Section 11:
"with an hi-target value of "mp" "
Whatever terminology we end up with from comment 49, we should align here too, e.g., "with an "mp" parameter".
Similarly for "rc" later in sentence.

56. Section 11:
"Since support for History-info header field is optional, a service
   MUST define default behavior for requests and responses not
   containing History-Info headers."
Change "History-Info headers" to "a History-Info header field".

57. Section 11:
"For example, an entity may receive
   only partial History-Info entries  or entries"
Surely each hi-entry will be a complete entry, but an entity might receive an incomplete set of hi-entries. Also correct the terminology. Change to:
"For example, an entity may receive an incomplete set of hi-entries"

58. Section 12:
If an entity forwards a request containing an hi-entry marked as private to another entity within the same domain, it expects that other entity to anonymize the hi-entry before forwarding outside the domain. However, what happens if that other entity doesn't support H-I? Presumably the RFC 3325 concept of Trust Domain needs to be extended somehow to RFC4424bis, such that for an entity to be considered in the same Trust Domain it must support RFC4424bis. There should be some discussion around this. See also comment 18.

John

---

From: Mary Barnes <[email-masked]>
Date: Tue, 29 Mar 2011 07:40:07 -0500

John,

Thanks for taking the time to review the updated doc.  Overall, I agree with
your suggestions for editorial clarifications and issue fixes - just a few
comments inline below [MB].

Mary.

On Wed, Mar 16, 2011 at 4:44 PM, Elwell, John <
[email-masked]> wrote:

> Mary,
>
> Thanks for adopting the principles I proposed. Although I agree with much
> of the minor rewording you carried out, I do have some issues as follows.
> Also I still need to comment on other parts of the document - these comments
> apply to sections 6 to 9 only.
>
> 1. Section 6:
> We should also observe that when a UAC is part of a B2BUA, the cache might
> not be empty (I failed to cover this in my proposed text). I suggest:
> 6. Section 7: In my opinion it would be more logical to list the 4 cases in
> order of the sections they reference (9.1, 9.2, 9.3, 9.4), as I proposed.
>
> 7. Section 7:
> This is wrong. ALL the procedures of 9.2 apply, not just the one about
> adding an hi-entry for the specific target. Just say "...MUST follow the
> procedures of Section 9.2" - don't try to repeat things from the referenced
> section.
>

[MB] It's not wrong - the intent was that all the procedures of 9.2 apply,
but I agree that your suggestion is much clearer. [/MB]

> The procedures of 9.3 cover ALL SIP responses, whether or not they contain
> hi-entries. For example,  if the UAS does not support H-I, it will not send
> back any hi-entries, but the procedures of 9.3 still apply to the
> intermediary that receives such a response. Delete "containing hi-entries"

> "This section describes the procedures for SIP entities for the handling of
> the History-Info header field in SIP requests and responses".
> My reasoning is that not all received requests and responses contain the
> header field, but there are still procedures that apply to such requests and
> responses, perhaps leading to the inclusion of the header field in forwarded
> requests/responses. So saying "SIP requests and responses containing the
> History-Info header fields" doesn't seem quite right.
>
> Delete 'to a value of "1"'. This is not always true, if there are
> hi-entries from upstream entities, but the hi-entry from the last entity is
> missing and needs to be added.
>
[MB]  That's fine - per your comment 7, it really is clearer to refer
directly to the sections rather than briefly (and incompletely) re-iterate
what is described in the referenced section. [/MB]

> "If the sent request is a direct result of retargeting to a contact URI
> received in a 3xx response and the Contact header field in that response
> contained an "rc" or "mp" header field parameter, the entity MUST include
> the corresponding parameter in the new hi-entry in accordance with 10.4."
> (although I am not certain the words "in accordance with 10.4 are needed -
> in retrospect I would delete those words)
>
[MB] Per your suggestions above (i.e, 7) in terms of not repeating things in
the referenced section, I thought that it was more confusing to include the
handling of 3xx responses in this section. [/MB]

> I find the words "In the former case" a little confusing. Also, if there
> are exceptions to the normative statement in the first sentence, they should
> probably be made clear in that first sentence. I would propose:
>   all the cached hi-entries in the response, subject to the privacy
> considerations in Section 10.1.2 and with the following

---

From: Mary Barnes <[email-masked]>
Date: Wed, 30 Mar 2011 00:09:25 -0500

John,

Thanks for the additional comments.  Per my other response, I agree with
your suggestions for the most part, with just a few responses inline below
[MB].

Thanks,
Mary.

On Fri, Mar 25, 2011 at 9:46 AM, Elwell, John <
[email-masked]> wrote:

> Mary,
>
> I already sent you my comments on sections 6 to 9. Now I finally got round
> to reading much of the rest of the document (up to section 12). Sorry, my
> energy ran out after that - I will leave it to others to check the rest. I
> have to say that these sections are not yet ready to go - quite a few
> inaccuracies and inconsistent use of terminology. Here goes:
>
> 1. Section 1:
> What is meant by "securing the header"? Why just the header and not the
> body? Surely the only means we are suggesting is TLS, which secures the body
> as well as the header.
>
[MB] The intent is that if the SIP header fields are protected, then you
have confidence that the values are real. That's not necessarily saying that
the bodies aren't also protected by TLS - it's just not mentioned since the
bodies aren't  relevant to History-Info header fields. I could change that
to "sending the messages using a secure transport". [/MB]

> What is bound? Presumably the contact, not the Request-URI, and not the
> request. Wording is ambiguous, because "that is bound" is too separated from
> "contact". Also "Request-URI is ambiguous - the Request-URI before or after
> retargeting. I think it should say something like "...is a contact bound to
> an AOR in an abstract location service, that AOR being the Request-URI that
> was retargeted."
>
> 5. Section 5:
> What is meant by "the value of the index" at the start of the sentence?
> Isn't this simply the value of the "mp" parameter? In any case, shouldn't we
> use a similar formulation to that used in the corresponding sentence in the
> definition of "rc"?
>
[MB] The "value of the index" refers the value of the "mp" header field
parameter which contains an "index" as defined by the ABNF. However, I'll
make the change as you suggest. [/MB]

> There is no definition of hi-target - I think it should be
> "hi-target-param". However, there are other places in the document where
> "hi-target" is referred to. I think hi-target-param is better - please align
> all instances.
>
> 8. Section5:
> To make it clear where in the hi-targeted-to-uri, I think it should say
> "...included in the "headers" component of the hi-targeted-to-uri".
>
> 10. Section 5:
> "A reason is
> Ambiguous. Does it mean it appears in the hi-entry for that URI, or does it
> mean it relates to that URI even though it appears in the URI resulting from
> retargeting? In addition, a reason can be included (and will appear in the
> response) even if there is no retargeting as a result of that reason. I
> would suggest: "A reason is included in the hi-targeted-to-uri of an
> hi-entry to reflect information received in a response to the request sent
> to that URI."
>
> 11. Section 5.1:
> "and
> I am not sure what this is talking about - if it is talking about "headers"
> component in a URI, I don't see any in the example. Delete this part of the
> sentence?
>
[MB] That's a hangover from the improper usage of "escape" in prior
versions. So, yes, I will delete. [/MB]

> I think 10.1.1 only describes insertion - it doesn't describe use on
> receipt. Change "the use of" to "the insertion of".
>
> 13. Section 10.1:
> I think this would be clearer if it said "Section 10.1.2 describes how to
> apply privacy to a request or response that is being forwarded, based on the
> presence of the Privacy header field."
>
> 14. Section 10.1.1:
> This seems to suggest it is used to indicate whether privacy is to be
> applied or not, but the bullets below are specific to the case where privacy
> IS to be applied. I would suggest "...to indicate that privacy is to be
> applied"
>
> 15. Section 10.1.1:
> Does "each hi-entry added by intermediary" include any hi-entries that have
> been received in responses from downstream entities, these hi-entries then
> being added to any additional branches?
>
[MB] No, it does not include the hi-entries added by the branches as the
entity that is doing the retargeting applies the privacy as appropriate.  If
the entities are in the same domain one would expect that the entity doing
the retargeting would indicate and apply privacy as appropriate. [/MB]

16. Section 10.1.2:
> I think the words "to ... a domain for which the SIP intermediary is not
> responsible" applies also when forwarding a response. Should it say:
> Where is "Privacy Service" defined (for priv-value "history")? Presumably
> the following paragraphs specify the Privacy Service, but this is not clear.
>
[MB] Privacy service is a logical role as defined in RFC 3323 and the next
paragraphs define the behavior for the entity serving in that logical role.
[/MB]

> How do we ensure the presence of a Privacy Service at a domain boundary?
> For example, a proxy inserts an hi-entry marked with privacy and sends it to
> the next node in its domain. But that node doesn't support H-I, so just
> passes H-I on transparently, perhaps outside the domain. There needs to be
> an element of trust here, similar to RFC 3325, where information subject to
> privacy is sent only to trusted entities within the domain, but furthermore,
> to be trusted an entity needs to support H-I. See also my last comment (on
> section 12).
>

[MB]    The protocol itself can't ensure the presence of a privacy service,
however, if whomever wants privacy applied needs to ensure that the entities
within its domain are capable of applying the required privacy when the
request leaves the domain. The privacy won't work unless all entities in the
domain have implemented this RFC (or 4244 for that matter.   I don't see
that adding the RFC 3325 trust domain model helps. We have also discussed
the latter in the past and we add ed clarification in section 2 that this
document is dealing with the definition of a domain as per RFC 3261 and we
aren't describing the use in the context of RFC 3325. [/MB]

> I think this is talking about a Privacy header field in the message header,
> as opposed to a Privacy header field in the "headers" component of an
> hi-targeted-to-uri. This should be made clear, although there is no obvious
> terminology we can call on. Perhaps:
> "If there is a Privacy header field in the request, other than in the
> "headers" component of an hi-targeted-to-uri, with a priv-value
[MB] Yes. [/MB]

> I think this is trying to say "a SIP intermediary  anonymizes any
> hi-targeted-to-uris associated with its own domain". But I am rather
> confused that this sentence talks about "a SIP intermediary" and the next
> sentence, which seems to repeat things in normative language, talks about
> "The Privacy Service". We could do with some rationalization of the two
> sentences.
>
[MB] The Privacy Service is a logical role as described in my response to 17
above. The usage of domain and SIP intermediary is used as described in
section 2.  I'll change the last part of that first sentence to "are
anonymized by the Privacy Service". [/MB]

> Again I think we need to qualify this by adding "other than in the
> "headers" component of an hi-targeted-to-uri".
>
> 23. Concerning the same sentence, again I have trouble with this sentence
> and the next sentence covering essentially the same thing with different
> terminology.
>
> 24. Section 10.2:
> According to 9.3 step 2, we add Reason to the cached hi-entries, and
> independently of whether the request then gets retargeted. I think it should
> say something like:  "To add Reason header fields to a cached hi-entry as a
> result of receiving a response to the request sent to the hi-entry's
> hi-targeted-to-uri, a SIP entity MUST use any Reason header fields received
> in the response"
>
[MB] See response to 25. [/MB]

> What if it is a 2xx response - does this make sense?
[MB] If it was a 2xx response, then we are not retargeting, which is the
subject of that sentence.  So, we should update 9.3 to read "other than a
100 or 2xx".  [/MB]

> Delete these words, because it gets added to the cached hi-entry
> independently of whether it is then retargeted.
>
[MB] Per my response above, it only gets added when it is retargeted. So, we
need to clarify this in section 9.3 which is caching.  However, there are
times when we need to cache an hi-entry so it gets sent in a response AND it
doesn't need to have a Reason header added. I think we introduced a bug when
the cache concept was introduced. [/MB]

> Does this mean "additional protocol values"? However, no specific protocol
> values are mentioned above, so why to we need to mention "additional"
> protocol values?
>
[MB] This is saying that if there are new Reason header field values
defined, then they also MUST be added to the hi-entry as described in that
section.  So, perhaps rather than "described above" we say "as described in
this section".  This is intended to mean that you don't need to  update HI
if you add new Reason header field values since this document references the
ones defined in RFC 3326.[/MB]

> What is "Basic Forwarding"?
[MB] We'll remove "basic". It's referring to when a request is sent from one
entity to another entity across different intermediary without changing the
target.[/MB]

> Any request can be forwarded eventually, even it has been retargeted,
> redirected, etc.. So how exactly does this case 1 differ from some of the
> other cases?
>
[MB]  See 30. [/MB]

32. Also in item 1:
> The new level is not, in general, level 1. I think this should say "An
> initial value of 1 for the new level." Unfortunately the ABNF fails to give
> a name to a single component of hi-index, so I have just called it "value".
>
> What exactly is "another branch"? RFC 3261 already talks about creating
> branches, so why do we need a normative statement here to tell us to do
> something that is normatively specified in RFC 3261? We should only be
> making normative statements that are specific to H-I.
>

[MB]  We meant to represent the additional branch by setting a hi-entry with
value incrementing the hi-entry of previous branch by 1.

Initial branch = 1.1.1
Second branch = 1.1.2

I guess we can remove the MUST add and change the following sentence
as follows.

"The SIP entity MUST calculate and add the hi-index for each new branch.."
[/MB]

> Since a value for a particular level within hi-index can comprise more than
> one digit, the word "digit" here is not correct. It is the integer that
> should be incremented.
>
[MB] It's not an integer.  We could say the lowest/last "value".[/MB]

> I don't think this is true. For example, I receive hi-entry 1.2, I fork
> first of all with hi-entry 1.2.1. This receives a response 4xx, so I then
> fork again, this time with hi-entry 1.2.2. I thought in this case hi-entry
> 1.2.1, as well as 1.2.2,  would be included in the new forwarded request
> (since 1.2.1 will be in the cache at this stage).
>
[MB] That just applies to parallel forking.  Will change to "Note, that in
the case of parallel forking, only the hi-entry corresponding to the fork
 is included in the request.[/MB]

> Wrong title - the section is to do with indicating how the target was
> determined, not with the determination mechanism itself. Perhaps "10.4
> Indicating the mechanism by which the target was determined..."
>
> 40. Section 10.4:
[MB] Meaning that those are not the only mechanisms by which a target is
determined - this goes back to when we had others identified and was added
when we changed it to not tag each hi-entry with something.  We can just
delete the "non-inclusive". [/MB]

> This doesn't make it clear that the Request-URI is the AOR. However, for
> both this and the "mp" bullet point, we should perhaps refer to section 5,
> where those are defined, rather than reproducing the definition here with
> the risk of it being different.
>
> 44. Section 10.4:
> I don't think this is right, since the issuer of the 3xx will build the rc
> or mp parameter, and therefore it will reference the index received by that
> entity. This could indeed be a sibling, but it could also be a child of a
> sibling, a child of a child of a sibling, and so on.
>
[MB]

> we do indeed intend it normatively.
[MB]   This is bascially saying that the SIP entity is the one that can
interpret the information and if there are gaps, it MUST NOT generate an
error but it just needs to provide an indication to the application that
there are gaps.   We added this MUST NOT generate an error based on a
comment from Hadriel a while back. I don't know what we can anticipate by
saying MUST indicate, as we aren't providing a protocol mechanism for the
indication.  There being a gap is an indication that there is a gap and that
is that.

46. Section 11:
> This is not true. The most complete is the complete set of hi-entries. Even
> if there are gaps, the information subsequent to the last gap will not be as
> complete as the total information.
>
[MB] We can just strike that sentence [/MB]

> I thinks these are only examples, rather than a summary of everything an
> application could used. Change "summarizes" to "examples".
>
[MB] I would prefer "describes some categories" [/MB]

> An index cannot match an entire hi-entry. I think this should say "the
> index that matches the value of the "rc" parameter in the last hi-
>       entry with ..."
> I am not sure that "header parameter" is the right way to describe "rc". It
> might be more accurate to say "hi-entry parameter" or, to use the ABNF name,
> "hi-target-parameter", or simply "parameter". Whatever is chosen, it needs
> to be consistent throughout the document.
[MB] "rc" is a header field parameter that is in an hi-entry. [/MB]

> This is confusing, because the Request-URI changes during retargeting, and
> it is not clear to which Request-URI and to which request we refer. Perhaps
> it means the final target, but that is not necessarily true - I am sure
> there must be some corner cases where there is a non-"rc" retarget after the
> last "rc" retarget. I think all we can say for certain is something like:
> "i.e., the last AOR that was retargeted to a contact based on an
> AOR-to-contact binding in an abstract location service." Note that a
> formulation like this would better match the style of the formulation in
> item 3.
>
> 51. Section 11, item 4:
> "thus the
> "thus the hi-entry that matches the value of the "rc" parameter of the
> first hi-entry with an "rc" parameter within the domain..."
> Surely each hi-entry will be a complete entry, but an entity might receive
> an incomplete set of hi-entries. Also correct the terminology. Change to:
> If an entity forwards a request containing an hi-entry marked as private to
> another entity within the same domain, it expects that other entity to
> anonymize the hi-entry before forwarding outside the domain. However, what
> happens if that other entity doesn't support H-I? Presumably the RFC 3325
> concept of Trust Domain needs to be extended somehow to RFC4424bis, such
> that for an entity to be considered in the same Trust Domain it must support
> RFC4424bis. There should be some discussion around this. See also comment
> 18.
>
[MB] See response to 18 above.  [/MB]

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 30 Mar 2011 10:47:44 +0200

Mary,

Thanks for your responses. Sorry I did not see this before the meeting. There are a few points where I am not entirely happy with your response, but nothing that really needed to be raised at the meeting - see below.

> From: Mary Barnes [mailto:[email-masked]]
> Sent: 30 March 2011 06:09
> To: Elwell, John
> Cc: SIPCORE
> Subject: Re: [sipcore] Fwd: I-D
> Thanks for the additional comments.  Per my other response, I
> agree with your suggestions for the most part, with just a
> few responses inline below [MB].
>
> Thanks,
> Mary.
>
> On Fri, Mar 25, 2011 at 9:46 AM, Elwell, John
> <[email-masked]> wrote:
>
>
>       Mary,
>
>       I already sent you my comments on sections 6 to 9. Now
> I finally got round to reading much of the rest of the
> document (up to section 12). Sorry, my energy ran out after
> that - I will leave it to others to check the rest. I have to
> say that these sections are not yet ready to go - quite a few
>       What is meant by "securing the header"? Why just the
> header and not the body? Surely the only means we are
> suggesting is TLS, which secures the body as well as the header.
>
>
> [MB] The intent is that if the SIP header fields are
> protected, then you have confidence that the values are real.
> That's not necessarily saying that the bodies aren't also
> protected by TLS - it's just not mentioned since the bodies
> aren't  relevant to History-Info header fields. I could
> change that to "sending the messages using a secure transport". [/MB]
>
>
>       3. Section 5:
>       What is bound? Presumably the contact, not the
> Request-URI, and not the request. Wording is ambiguous,
> because "that is bound" is too separated from "contact". Also
> "Request-URI is ambiguous - the Request-URI before or after
> retargeting. I think it should say something like "...is a
> contact bound to an AOR in an abstract location service, that
> AOR being the Request-URI that was retargeted."
>
>       5. Section 5:
>       What is meant by "the value of the index" at the start
> of the sentence? Isn't this simply the value of the "mp"
> parameter? In any case, shouldn't we use a similar
> formulation to that used in the corresponding sentence in the
> definition of "rc"?
>
>
> [MB] The "value of the index" refers the value of the "mp"
> header field parameter which contains an "index" as defined
> by the ABNF. However, I'll make the change as you suggest. [/MB]
>
>
>       7. Section 5:
>       There is no definition of hi-target - I think it should
> be "hi-target-param". However, there are other places in the
> document where "hi-target" is referred to. I think
> hi-target-param is better - please align all instances.
>
>       8. Section5:
>       I think it should say "...and/or a Privacy header
> field. We can have one without the other.
>
>       9. Section 5:
>       "which
>       To make it clear where in the hi-targeted-to-uri, I
> think it should say "...included in the "headers" component
> of the hi-targeted-to-uri".
>
>       10. Section 5:
>       "A reason is
>       Ambiguous. Does it mean it appears in the hi-entry for
> that URI, or does it mean it relates to that URI even though
> it appears in the URI resulting from retargeting? In
> addition, a reason can be included (and will appear in the
> response) even if there is no retargeting as a result of that
> reason. I would suggest: "A reason is included in the
> hi-targeted-to-uri of an hi-entry to reflect information
> received in a response to the request sent to that URI."
>
>       11. Section 5.1:
>       "and
>       I am not sure what this is talking about - if it is
> talking about "headers" component in a URI, I don't see any
> in the example. Delete this part of the sentence?
>
>
> [MB] That's a hangover from the improper usage of "escape" in
> prior versions. So, yes, I will delete. [/MB]
>
>
>       12. Section 10.1:
>       I think 10.1.1 only describes insertion - it doesn't
> describe use on receipt. Change "the use of" to "the insertion of".
>
>       13. Section 10.1:
>       I think this would be clearer if it said "Section
> 10.1.2 describes how to apply privacy to a request or
> response that is being forwarded, based on the presence of
> the Privacy header field."
>
>       14. Section 10.1.1:
>       This seems to suggest it is used to indicate whether
> privacy is to be applied or not, but the bullets below are
> specific to the case where privacy IS to be applied. I would
> suggest "...to indicate that privacy is to be applied"
>
>       15. Section 10.1.1:
>       Does "each hi-entry added by intermediary" include any
> hi-entries that have been received in responses from
> downstream entities, these hi-entries then being added to any
> additional branches?
>
>
> [MB] No, it does not include the hi-entries added by the
> branches as the entity that is doing the retargeting applies
> the privacy as appropriate.  If the entities are in the same
> domain one would expect that the entity doing the retargeting
> would indicate and apply privacy as appropriate. [/MB]
[JRE] Perhaps you could add some words to clarify that.

>       I think the words "to ... a domain for which the SIP
> intermediary is not responsible" applies also when forwarding
> a response. Should it say:
>       Where is "Privacy Service" defined (for priv-value
> "history")? Presumably the following paragraphs specify the
> Privacy Service, but this is not clear.
>
>
> [MB] Privacy service is a logical role as defined in RFC 3323
> and the next paragraphs define the behavior for the entity
> serving in that logical role. [/MB]
[JRE] My problem was that Privacy Service as defined in RFC 3323 does include H-I - but if others are comfortable with the existing text I can live with it.

>       How do we ensure the presence of a Privacy Service at a
> domain boundary? For example, a proxy inserts an hi-entry
> marked with privacy and sends it to the next node in its
> domain. But that node doesn't support H-I, so just passes H-I
> on transparently, perhaps outside the domain. There needs to
> be an element of trust here, similar to RFC 3325, where
> information subject to privacy is sent only to trusted
> entities within the domain, but furthermore, to be trusted an
> entity needs to support H-I. See also my last comment (on section 12).
>
>
>
> [MB]    The protocol itself can't ensure the presence of a
> privacy service, however, if whomever wants privacy applied
> needs to ensure that the entities within its domain are
> capable of applying the required privacy when the request
> leaves the domain. The privacy won't work unless all entities
> in the domain have implemented this RFC (or 4244 for that
> matter.   I don't see that adding the RFC 3325 trust domain
> model helps. We have also discussed the latter in the past
> and we add ed clarification in section 2 that this document
> is dealing with the definition of a domain as per RFC 3261
> and we aren't describing the use in the context of RFC 3325. [/MB]
[JRE] Perhaps this is something that can be address in Security Considerations - see my later comment.

>       I think this is talking about a Privacy header field in
> the message header, as opposed to a Privacy header field in
> the "headers" component of an hi-targeted-to-uri. This should
> be made clear, although there is no obvious terminology we
> can call on. Perhaps:
>       "If there is a Privacy header field in the request,
> other than in the "headers" component of an
> hi-targeted-to-uri, with a priv-value
>       20. The same quoted text talks about requests, but
> don't we need similar procedures for responses?
>
>
> [MB] Yes. [/MB]
>
>
>       I think this is trying to say "a SIP intermediary
> anonymizes any hi-targeted-to-uris associated with its own
> domain". But I am rather confused that this sentence talks
> about "a SIP intermediary" and the next sentence, which seems
> to repeat things in normative language, talks about "The
> Privacy Service". We could do with some rationalization of
> the two sentences.
>
>
> [MB] The Privacy Service is a logical role as described in my
> response to 17 above. The usage of domain and SIP
> intermediary is used as described in section 2.  I'll change
> the last part of that first sentence to "are anonymized by
> the Privacy Service". [/MB]
>
>
>       22. Section 10.1.2:
>       Again I think we need to qualify this by adding "other
> than in the "headers" component of an hi-targeted-to-uri".
>
>       23. Concerning the same sentence, again I have trouble
> with this sentence and the next sentence covering essentially
> the same thing with different terminology.
>
>       24. Section 10.2:
>       According to 9.3 step 2, we add Reason to the cached
> hi-entries, and independently of whether the request then
> gets retargeted. I think it should say something like:  "To
> add Reason header fields to a cached hi-entry as a result of
> receiving a response to the request sent to the hi-entry's
> hi-targeted-to-uri, a SIP entity MUST use any Reason header
> fields received in the response"
>
>
[JRE] I don't see the relevance of 25 - 24 and 25 are quite different comments.

> [MB] If it was a 2xx response, then we are not retargeting,
> which is the subject of that sentence.  So, we should update
> 9.3 to read "other than a 100 or 2xx".  [/MB]
>
>
>       Delete these words, because it gets added to the cached
> hi-entry independently of whether it is then retargeted.
>
>
> [MB] Per my response above, it only gets added when it is
> retargeted. So, we need to clarify this in section 9.3 which
> is caching.  However, there are times when we need to cache
> an hi-entry so it gets sent in a response AND it doesn't need
> to have a Reason header added. I think we introduced a bug
> when the cache concept was introduced. [/MB]
>
>
>       27. Section 10.2:
>       "containing a SIP
>       Does this mean "additional protocol values"? However,
> no specific protocol values are mentioned above, so why to we
> need to mention "additional" protocol values?
>
>
> [MB] This is saying that if there are new Reason header field
> values defined, then they also MUST be added to the hi-entry
> as described in that section.  So, perhaps rather than
> "described above" we say "as described in this section".
> This is intended to mean that you don't need to  update HI if
> you add new Reason header field values since this document
> references the ones defined in RFC 3326.[/MB]
[JRE] So "additional" means additional to those currently specified in RFCs, or "new protocol values specified in the future".

> [MB] We'll remove "basic". It's referring to when a request
> is sent from one entity to another entity across different
> intermediary without changing the target.[/MB]
[JRE] so make it clear that we are not changing the target, e.g., "Forwarding a request without changing the target".

>       Any request can be forwarded eventually, even it has
> been retargeted, redirected, etc.. So how exactly does this
> case 1 differ from some of the other cases?
>
>
> [MB]  See 30. [/MB]
>
>
>       32. Also in item 1:
>       "MUST
>       The new level is not, in general, level 1. I think this
> should say "An initial value of 1 for the new level."
> Unfortunately the ABNF fails to give a name to a single
> component of hi-index, so I have just called it "value".
>
>       What exactly is "another branch"? RFC 3261 already
> talks about creating branches, so why do we need a normative
> statement here to tell us to do something that is normatively
> specified in RFC 3261? We should only be making normative
> statements that are specific to H-I.
>
>
>
> [MB]  We meant to represent the additional branch by setting
> a hi-entry with value incrementing the hi-entry of previous
> branch by 1.
>
> Initial branch = 1.1.1
> Second branch = 1.1.2
>
>       Since a value for a particular level within hi-index
> can comprise more than one digit, the word "digit" here is
> not correct. It is the integer that should be incremented.
>
>
>       I don't think this is true. For example, I receive
> hi-entry 1.2, I fork first of all with hi-entry 1.2.1. This
> receives a response 4xx, so I then fork again, this time with
> hi-entry 1.2.2. I thought in this case hi-entry 1.2.1, as
> well as 1.2.2,  would be included in the new forwarded
> request (since 1.2.1 will be in the cache at this stage).
>
>
> [MB] That just applies to parallel forking.  Will change to
> "Note, that in the case of parallel forking, only the
> hi-entry corresponding to the fork  is included in the request.[/MB]
>
>
>       Wrong title - the section is to do with indicating how
> the target was determined, not with the determination
> mechanism itself. Perhaps "10.4 Indicating the mechanism by
> which the target was determined..."
>
>       40. Section 10.4:
> [MB] Meaning that those are not the only mechanisms by which
> a target is determined - this goes back to when we had others
> identified and was added when we changed it to not tag each
> hi-entry with something.  We can just delete the
> "non-inclusive". [/MB]
[JRE] I would have thought we would use "non-exclusive", i.e., we are not excluding other mechanisms. Anyway, I am happy with deletion.

>       I think this should say "in the case of retargeting to
> a contact URI received in a 3xx response".
>
>       42. Section 10.4:
>       This doesn't make it clear that the Request-URI is the
> AOR. However, for both this and the "mp" bullet point, we
> should perhaps refer to section 5, where those are defined,
> rather than reproducing the definition here with the risk of
> it being different.
>
>       44. Section 10.4:
>       I don't think this is right, since the issuer of the
> 3xx will build the rc or mp parameter, and therefore it will
> reference the index received by that entity. This could
> indeed be a sibling, but it could also be a child of a
[JRE] Were you attempting to add a remark here?

>       I think changing "rather indicate" to "MUST indicate"
> would be clearer, if we do indeed intend it normatively.
>
>
> [MB]   This is bascially saying that the SIP entity is the
> one that can interpret the information and if there are gaps,
> it MUST NOT generate an error but it just needs to provide an
> indication to the application that there are gaps.   We added
> this MUST NOT generate an error based on a comment from
> Hadriel a while back. I don't know what we can anticipate by
> saying MUST indicate, as we aren't providing a protocol
> mechanism for the indication.  There being a gap is an
> indication that there is a gap and that is that.
[JRE] So I would say "should indicate".

>       This is not true. The most complete is the complete set
> of hi-entries. Even if there are gaps, the information
> subsequent to the last gap will not be as complete as the
> total information.
>
>
>       I thinks these are only examples, rather than a summary
> of everything an application could used. Change "summarizes"
> to "examples".
>
>
>       An index cannot match an entire hi-entry. I think this
> should say "the index that matches the value of the "rc"
> parameter in the last hi-
>             entry with ..."
>       I am not sure that "header parameter" is the right way
> to describe "rc". It might be more accurate to say "hi-entry
> parameter" or, to use the ABNF name, "hi-target-parameter",
> or simply "parameter". Whatever is chosen, it needs to be
> consistent throughout the document.
>       This is confusing, because the Request-URI changes
> during retargeting, and it is not clear to which Request-URI
> and to which request we refer. Perhaps it means the final
> target, but that is not necessarily true - I am sure there
> must be some corner cases where there is a non-"rc" retarget
> after the last "rc" retarget. I think all we can say for
> certain is something like: "i.e., the last AOR that was
> retargeted to a contact based on an AOR-to-contact binding in
> an abstract location service." Note that a formulation like
> this would better match the style of the formulation in item 3.
>
>       51. Section 11, item 4:
>       "thus the
>       "thus the hi-entry that matches the value of the "rc"
> parameter of the first hi-entry with an "rc" parameter within
> the domain..."
>       Whatever terminology we end up with from comment 49, we
> should align here too, e.g., "with an "mp" parameter".
>       Surely each hi-entry will be a complete entry, but an
> entity might receive an incomplete set of hi-entries. Also
> correct the terminology. Change to:
>       If an entity forwards a request containing an hi-entry
> marked as private to another entity within the same domain,
> it expects that other entity to anonymize the hi-entry before
> forwarding outside the domain. However, what happens if that
> other entity doesn't support H-I? Presumably the RFC 3325
> concept of Trust Domain needs to be extended somehow to
> RFC4424bis, such that for an entity to be considered in the
> same Trust Domain it must support RFC4424bis. There should be
> some discussion around this. See also comment 18.
>
>
[JRE] I really think this is something that should be described in Security Considerations.

John