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

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

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.


> -----Original Message-----
> From: Mary Barnes [mailto:[e-mail]]
> Sent: 30 March 2011 06:09
> To: Elwell, John
> Cc: SIPCORE
> Subject: Re: [sipcore] Fwd: I-D
> ACTION:draft-ietf-sipcore-rfc4244bis-04.txt
>
> 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
> <[e-mail]> 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:
>       "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.
>
>
> [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:
>       "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"?
>
>
> [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:
>       "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?
>
>
> [MB] That's a hangover from the improper usage of "escape" in
> prior versions. So, yes, I will delete. [/MB]
>
>
>       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?
>
>
> [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.

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

>
>
>       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).
>
>
>
> [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.

>
>
>       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?
>
>
> [MB] Yes. [/MB]
>
>
>       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.
>
>
> [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:
>       "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"
>
>
> [MB] See response to 25. [/MB]
[JRE] I don't see the relevance of 25 - 24 and 25 are quite different comments.


>
>
>       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?
>
>
> [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]
>
>
>       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.
>
>
> [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
>         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?
>
>
> [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".

>
>
>       30. Section 10.3:
>       "Basic Forwarding: "
>       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]
[JRE] so make it clear that we are not changing the target, e.g., "Forwarding a request without changing the target".

>
>
>       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?
>
>
> [MB]  See 30. [/MB]
>
>
>       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.
>
>
>
> [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]
>
>
>
>       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.
>
>
> [MB] It's not an integer.  We could say the lowest/last "value".[/MB]
>
>
>       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).
>
>
> [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]
>
>
>       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.
>
>
> [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.

>
>
>       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.
>
>
> [MB]
[JRE] Were you attempting to add a remark here?


>
>
>       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.
>
>
> [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".

>
>
>
>       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.
>
>
> [MB] We can just strike that sentence [/MB]
>
>
>       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".
>
>
> [MB] I would prefer "describes some categories" [/MB]
>
>
>       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.
>
>
> [MB] "rc" is a header field parameter that is in an hi-entry. [/MB]
>
>
>       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.
>
>
> [MB] See response to 18 above.  [/MB]
[JRE] I really think this is something that should be described in Security Considerations.

John



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