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

["Elwell, John" <[e-mail]>]

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

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] 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:
>
> 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: <[e-mail]>
> Date: Tue, Mar 15, 2011 at 1:30 PM
> Subject: I-D ACTION:draft-ietf-sipcore-rfc4244bis-04.txt
> To: [e-mail]
> Cc: [e-mail]
>
>
> 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-rfc4244
> bis-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.
>
>
> _______________________________________________
> I-D-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft
> <https://www.ietf.org/mailman/listinfo/i-d-announceInternet-Dr
> aft>  directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>
>