Re: [sipcore] Fwd: Updates to draft-ietf-sipcore-rfc4244bis-11, version 1.

[Mary Barnes <[e-mail]>]

On Tue, Feb 19, 2013 at 10:50 AM, Paul Kyzivat <[e-mail]> wrote:
> Mary & Dale,
>
> This is very hard to follow.
> But I do get it that the two of you are getting closer but still not in
> total agreement. Can the two of you reach a mutually satisfactory
> conclusion?
>
> I'd love to have a new version with a direct diff to evaluate it all.
>
> I must say that I am surprised that so much effort was put into the
> hierarchical numbering scheme for entries and yet the conclusion is that the
> entries are not sorted in accord with this hierarchy. (Or did I get that
> wrong?)

[MB] As I highlighted to Dale, within an entity they are in order.
The issue is due to the fact that not all entities will support HI,
thus you cannot guarantee that the lexicographical order is meaningful
(amongst all the entities).  Since we do require an entity to add the
entries in chronological order using the indexing scheme as specifed
they are in order for that entity.  When the request is forwarded and
a response contains additional hi-entires (due to retargeting at the
next hop), the ordering is guaranteed for the entity to which the
request was forwarded.  The issue comes when you get a reset to 0
indicating an entity did not support HI, then you lose any ordering.
[/MB]
>
>         Thanks,
>         Paul
>
>
> On 2/19/13 11:16 AM, Mary Barnes wrote:
>>
>> Hi all,
>>
>> This is a set of suggested changes from Dale based upon the comments
>> he sent to the list previously:
>> http://www.ietf.org/mail-archive/web/sipcore/current/msg05489.html
>>
>> Responses are inline below [MB].   Based upon my responses, I do not
>> believe any of the changes impact normative behavior (as intended)
>> thus another WG and/or IETF LC should not be necessary, but I will
>> leave that decision to the chairs/AD.
>>
>> Mary.
>>
>>
>> ---------- Forwarded message ----------
>> From: Dale R. Worley <[e-mail]>
>> Date: Wed, Feb 6, 2013 at 9:09 AM
>> Subject: Updates to draft-ietf-sipcore-rfc4244bis-11, version 1.
>> To: [e-mail], [e-mail]
>>
>>
>> Here are my proposed fixes to the -11 version.  I believe that all of
>> these changes are non-controverisial, in that they adjust the document
>> to express what we all agree it ought to mean.  But in a number of
>> places, the prescribed procedures are actually different from the
>> current text.  Please review this and get back to us with your
>> thoughts.
>>
>> Thanks,
>>
>> Dale
>>
>> ======================================================================
>>
>> Updates to draft-ietf-sipcore-rfc4244bis-11, version 1.
>>
>> This document is organized as a series of responses to the points in
>> my e-mail of 18 Jan
>> (http://www.ietf.org/mail-archive/web/sipcore/current/msg05489.html).
>>
>> ==========
>>
>>> From: [e-mail] (Dale R. Worley)
>>> To: SIPCORE <[e-mail]>
>>> Subject: [sipcore] Questions about draft-ietf-sipcore-rfc4244bis-11.txt
>>> Date: Fri, 18 Jan 2013 12:10:40 -0500 (EST)
>>>
>>> I've got a few questions about 4244bis.  I think that there are
>>> understood answers to most of them, but we might have to update the
>>> wording to remove ambiguity.
>>
>>
>> ==========
>>
>>> 1. When an entity receives a (non-100) provisional response to a
>>> request, should it modify the hi-entry by adding a Reason value
>>> carrying the status of the response?  The current text (section 10.2)
>>> clearly requires it.  If the request eventually receives a failure
>>> response, the 1xx Reason will (probably) later be replaced by the
>>> failure code.  (But not necessarily:  see section 10.2 paragraph 3.)
>>>
>>> The only example in draft-ietf-sipcore-rfc4244bis-callflows-01 of this
>>> situation is section 3.1 message F8, and the 180 status is not
>>> reported in a Reason header-value for <sip:[e-mail]> (which
>>> thus contradicts section 10.2).
>>>
>>> The alternative is that 1xx responses do not set the Reason value
>>> (although they do add to the cache any new hi-entries they carry).
>>> This would require changing the text in section 9.3 step 2 and section
>>> 10.2.
>>
>>
>> NOTE:  I am assuming that non-100 provisional responses are intended
>> to carry hi-entries upstream, and that proxies that see those
>> responses are intended to cache the hi-entries carried in them.
>> (Those cached hi-entries can later be updated by a final response
>> which adds a Reason header value to them.)  If this is not so, these
>> changes need to be revised.
>>
>> As far as I can tell, we have never intended for receipt of a
>> provisional (1xx) response to an INVITE to set a Reason header on the
>> corresponding cached hi-entry.  The only example in 4244bis-callflows
>> of this situation is message F6 of section 3.1, in which there would
>> be a Reason header on hi-entries 1.2 and 1.2.1 -- and there is not.
>> And RFC 4244, which also has the Reason header value mechanism, does
>> not specify that 1xx responses set Reason header values.
>>
>> So I propose that we all agree that 1xx responses should not generate
>> Reason headers and we edit the text accordingly.
>> [MB] Correct.  That's been the intent for both 4244 and 4244bis.
>> It's mentioned in 9.4 that the HI is not sent in 100 responses (since
>> those do not result in retargeting), thus there would be no reason to
>> add a Reason header to anything.  [/MB]
>>
>>   The changes are:
>>
>>     section 9.3 step 2
>>
>>     Step 2:  Add Reason header field
>>
>>        The SIP entity adds one or more Reason header fields to the hi-
>> ------^
>> change "The" to "If the response code is not 1xx, the"
>>        targeted-to-uri in the (newly) cached hi-entry reflecting the SIP
>>        response code in the non-100 response, per the procedures of
>> ---------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> delete(?)
>>        Section 10.2.
>>
>> This change results in:
>>
>>        If the response code is not 1xx, the SIP entity adds one or more
>>        Reason header fields to the hi-targeted-to-uri in the (newly)
>>        cached hi-entry reflecting the SIP response, per the procedures
>>        of Section 10.2.
>>
>> [MB] Note that the section is specific to non-100 responses, which is
>> why it is written as it currently is.
>> I don't see that your suggested text adds any more information - i.e.,
>> the IF isn't necessary.  We are stating specific behavior for that
>> specific step and an "IF" isn't necessary.  I do not think this change
>> is necessary. [/MB]
>>
>>     10.2.  Reason in the History-Info Header Field
>>
>>     A Reason header field is added to the "headers" component in an hi-
>>     targeted-to-uri when the hi-entry is added to the cache based upon
>>     the receipt of a non-100 or non-2xx SIP response, as described in
>>     Section 9.3.  If the Reason header field is being added 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 "headers" component of the
>>     hi-targeted-to-uri in the last hi-entry added to the cache, unless
>>     the hi-targeted-to-uri is a Tel-URI.  If the SIP response does not
>>     contain a Reason header field, the SIP entity MUST include a Reason
>>     header field, containing the SIP Response Code, in the "headers"
>>     component of the hi-targeted-to-uri in the last hi-entry added to the
>>     cache, unless the hi-targeted-to-uri is a Tel-URI.
>>
>> The changes to this paragraph are extensive enough that I am not
>> showing the individual differences.  Note I have changed "the last
>> hi-entry added to the cache" to "the corresponding hi-entry".  The
>> latter makes more sense to me, and specifies the same hi-entry.  But
>> others may prefer the current description, in which case we can retain
>> it.
>>
>> The new version of this paragraph is:
>>
>>     A Reason header field is added to the "headers" component in an hi-
>>     targeted-to-uri when a non-100, non-2xx SIP response is received to
>>     the corresponding INVITE, or when a response is received containing
>>     the hi-entry with a Reason header value, as described in Section
>>     9.3.
>> [MB] You have dropped the reference to the cache here and that very
>> important.  I think it's obvious that we
>> are dealing with the corresponding INVITE.  When we talk about SIP
>> responses, we do not qualify it as "the SIP response received to the
>> corresponding INVITE".  But, it certainly causes no harm.  I would
>> suggest that sentence read:
>>     A Reason header field is added to the "headers" component in an hi-
>>     targeted-to-uri when the hi-entry is added to the cache based upon
>>     the receipt of a non-100 or non-2xx SIP response to the
>> corresponding INVITE, as described in
>>     Section 9.3.
>>
>> [/MB]
>>
>>     If the Reason header value is being added to an hi-targeted-to-uri
>>     due to receipt of an explicit SIP response to the corresponding
>>     INVITE and the response contains any Reason header fields (see
>>     [RFC3326]), then the SIP entity MUST also include the Reason header
>>     fields in the "headers" component of the hi-targeted-to-uri in the
>>     corresponding cached hi-entry, unless the hi-targeted-to-uri is a
>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>     Tel-URI.  If the SIP response does not contain a Reason header
>>     field with a protocol of "SIP", the SIP entity MUST include a
>>     Reason header field, containing the SIP Response Code, in the
>>     "headers" component of the hi-targeted-to-uri in the corresponding
>>     cached hi-entry, unless the hi-targeted-to-uri is a Tel-URI.
>>
>> [MB]  Note, you dropped "field" from the "Reason header value above,
>> which is not correct. So the real changes I see above are with regards
>> to highlighting that it's the corresponding cached hi-entry (rather
>> than the last.  I have annotated above that that is the only change
>> (AFAICT).  I can make that change as follows:
>> OLD:
>>      If the Reason header field is being added 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 "headers" component of the
>>      hi-targeted-to-uri in the last hi-entry added to the cache, unless
>>      the hi-targeted-to-uri is a Tel-URI.
>>
>> NEW:
>>     If the Reason header field is being added due to receipt of an
>> explicit
>>     SIP response to the corresponding INVITE
>>                                      ^^^^^^^^^^^^^^^^^^^^^^
>>     and the response contains any
>>     Reason header fields (see [RFC3326]), then the SIP entity MUST
>>     include the Reason header fields in the "headers" component of the
>>     hi-targeted-to-uri in the corresponding cached hi-entry,  unless
>>                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>     the hi-targeted-to-uri is a Tel-URI.
>> [/MB]
>>
>> There is a slight change here in that if the response contains
>> "Reason: Q.850;cause=14", then both the Q.850 response code and the
>> SIP response code will be recorded in the cached hi-entry.  The
>> previous text caused only the Q.850 response code to be recorded.
>> [MB] I don't see that the previous text said that only the Q.850
>> response code was recorded.
>> The text says that "Reason header fields" as in plural fields are added.
>> [/MB]
>>
>> If a Reason header includes a reason-value with protocol "SIP", that
>> reason-value is recorded instead of the response code in the response.
>> (This is the same as the previous text.)
>>
>> ==========
>>
>>> 2. During the life of the document, there was confusion about how
>>> hi-entries were to be organized.  The intention of the original writer
>>> and the current draft is that hi-entries are accumulated in a cache in
>>> the order the entity receives them (in requests and responses),
>>> allowing hi-entries that have the *same* index but *different* URIs,
>>> and (implicitly) eliminating duplicates.
>>
>> [MB] It wasn't just the original author and the current author, this
>> has been the intent of
>> the document and the approach was agreed by the WG. Certainly, there were
>> some
>> errors that might have lead one to believe otherwise, but that was
>> never the intent. [/MB]
>>>
>>>
>>> But some people who have worked on the draft (including myself) were
>>> for a while mistaken in believing that the hi-entries were to be
>>> organized into a tree, and hence the index values needed to be unique,
>>> and the History-Info header would list the hi-entries in tree-walking
>>> order (technically, "preorder").  The confusion was abetted by there
>>> being no examples that distinguish the two techniques.
>>
>> [MB] I think the confusion is that if everyone supported HI, you would
>> get a tree.
>> You can still get a somewhat pruned tree using the indices.  I think
>> the confusion is that the RFC never
>> had any intention of defining application behavior.  It is merely
>> recording what happens at the SIP protocol level. That's it.  How an
>> application uses the information (whether to build a tree or whatever)
>> is out of scope. [/MB]
>>>
>>> Unfortunately, the -11 draft doesn't eliminate all the remnants of the
>>> mistake.  I haven't gone through -11 in detail, but "preorder" appears
>>> in section 9.2 and section 10.3, so at least those sections describe
>>> the accumulation of hi-entries incorrectly.
>>
>>
>> The fix to this issue overlaps the fix for issue #4:
>>
>>> 4. If a downstream entity that does not support History-Info forks a
>>> request to entities that do support History-Info, an entity can
>>> receive two hi-entries with the same index that were not generated for
>>> the same fork of the request.  Conversely, an entity will receive
>>> responses that contain hi-entries that are duplicates of entries that
>>> are already in the cache.
>>>
>>> These facts imply that there is a process by which an entity
>>> determines whether a received hi-entry is "the same" as an hi-entry
>>> already in the cache (and so doesn't need to be added again).  Since
>>> index values cannot be depended upon to be unique, we really ought to
>>> state what the comparison rule is.
>>>
>>> I think it is sufficient to use the rule "the same index value and the
>>> URIs are equivalent (per RFC 3261 section 19.1.4, but ignoring the
>>> Reason header fields)".  This won't always give the result one would
>>> want (if a non-supporting downstream element forks the request to two
>>> target URIs that ultimately arrive at the same element, two hi-entries
>>> could be generated with the same index and URI), but this rule is
>>> simple, well-defined, and should work well in almost all situations.
>>
>>
>> In addition, when a response is received, it may contain hi-entries
>> that are duplicates of hi-entries already in the cache, except they
>> contain Reason header values that are not in the cached hi-entries.  I
>> believe we intend that the cached hi-entries be updated to include the
>> received Reason header values.
>>
>> The edits to fix these three issues are:
>>
>>     9.2.  Sending a Request with History-Info
>>
>>     When sending a request, a SIP entity MUST include all the hi-entries
>>     from the cache that was created per Section 9.1.  In addition, the
>>     SIP entity MUST add a new hi-entry to the outgoing request, but the
>>     SIP entity MUST NOT add the hi-entry to the cache at this time.  The
>> --------------------------------------------------------------------^
>> Change this sentence to:  "The hi-entries in the outgoing request's
>> History-Info header are in the order of the hi-entries in the cache,
>> which is the order in which they were added to the cache."
>>
>> [MB] That's fine. And, just for clarification, the statement below is
>> the OLD and the one above is the NEW [/MB]
>>
>>     hi-entries in the outgoing request's History-Info header field is the
>>     preorder of the tree of hi-entries, that is, by the lexicographic
>>     ordering of the hi-indexes.  The new hi-entry is populated as
>>     follows:
>>
>>     9.3.  Receiving a Response with History-Info or Request Timeouts
>>
>>     Step 1:  Add hi-entry to cache
>>
>>        The SIP entity MUST add the hi-entry that was added to the request
>> -----------------------------^
>> For clarity insert "to the cache" here, and...
>>        that received the non-100 response or timed out to the cache, if
>> ------------------------------------------------------^^^^^^^^^^^^
>> ... remove "to the cache" here.
>>        it was not already cached.  The hi-entry MUST be added to the
>> ----------------------------------^
>> Change this sentence to "If so, the hi-entry MUST be added to the end
>> of the cache."
>>
>>        cache in ascending order as indicated by the values in the hi-
>>        index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2
>>        but before 1.2.2 or 1.3).
>>
>> [MB] I can't decipher the changes you are suggesting above.  I think I
>> see your point.  However,
>> there is something very subtle here.  This is dealing with responses
>> and we add the hi-entries once we
>> get the response.  However, the value of the hi-index actually does
>> reflect a chronological order in terms of generating requests.  As
>> discussed previously, you lose that chronological ordering across
>> entities, but for a specific
>> SIP entity they do reflect the chronological processing at that
>> entity.  So, I don't think this is broken.  With the cache
>> model, we aren't adding them to the cache until we get the response
>> even though they were added to the request (in both chronological and
>> lexicographical order).
>> [/MB]
>>
>>
>>     9.3.  Receiving a Response with History-Info or Request Timeouts
>>
>>     Step 3:  Add additional hi-entries
>>
>>        The SIP entity MUST also add to the cache any hi-entries received
>>        in the response that are not already in the cache.  This situation
>>        can occur when the entity that generated the non-100 response
>>        retargeted the request before generating the response.  As per
>>        Step 1, the hi-entries MUST be added to the cache in ascending
>>        order as indicated by the values in the hi-index parameters of the
>>        hi-entries
>>
>> This paragraph needs more extensive changes:
>> [MB] It's not clear to me why you think it needs to be done this way.
>> This is still mapping back to the original request sent by a specific
>> entity (e.g., Proxy A).   I think you are confused by the scenario
>> being described.  The retargeting was not done by Proxy A that is
>> caching the hi-entries.  It was done by Proxy B that received the
>> request and it retargeted before returning the 1xx response thus there
>> is an additional hi-entry that Proxy A should add to its cache. [/MB]
>>
>>     Step 3:  Add and update additional hi-entries
>>
>>        The SIP entity MUST also add to the cache any hi-entries received
>>        in the response that are not already in the cache.  This
>>        can occur when the entity that generated the non-100 response
>>        retargeted the request before generating the response.  Such
>>        hi-entries MUST be added to the end of the cache in the order
>>        they appear in the History-Info header field of the response.
>>
>>        If an hi-entry in the response contains Reason header value(s)
>>        and the matching hi-entry in the cache does not, the Reason
>>        header value(s) MUST be added to the cached hi-entry.  This can
>>        occur when the hi-entry was added to the cache by a provisional
>>        response to an INVITE that was further retargeted, and later a
>>        final response to that INVITE is received.
>>
>>        In these cases, an hi-entry in a response's History-Info header
>>        field and an hi-entry in the cache are considered matching when
>>        they have the same index value and the hi-targeted-to-uris are
>>        equivalent (per RFC 3261 section 19.1.4, but ignoring the Reason
>>        header fields).
>>
>>     10.2.  Reason in the History-Info Header Field
>>
>>     A Reason header field is added to the "headers" component in an hi-
>>     targeted-to-uri when the hi-entry is added to the cache based upon
>> ----------------------------------------^^^^^^^^
>> change to "added to, or updated within,"
>>
>>     the receipt of a non-100 or non-2xx SIP response, as described in
>>     Section 9.3.  [...]
>> [MB] Why "updated within"?  [/MB]
>>
>>     10.3.  Indexing in the History-Info Header Field
>>
>>     In order to maintain ordering and accurately reflect the retargeting
>>     of the request, the SIP entity MUST add a hi-index to each hi-entry.
>>     Per the syntax in Section 5, the hi-index consists of a series of
>>     nonnegative integer separated by dots (e.g., 1.1.2).  Each dot
>>     reflects a SIP forwarding hop.  The nonnegative integer following
>>     each dot reflects the order in which a request was retargeted at the
>>     hop.  The highest nonnegative integer at each hop reflects the number
>>     of entities to which the request has been retargeted at the specific
>>     hop (i.e., the number of branches) at the time that the request
>>     represented by this hi-entry was generated.  Thus, the indexing
>>     results in a logical tree representation for the history of the
>>     request and the hi-entries are given in the preorder of the tree.
>> -----------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> delete this clause
>> [MB] Okay. [/MB]
>>
>> ==========
>>
>>> 3. Due to the confusion discussed in #2, we have to consider whether
>>> consensus was actually found in the WGLC.
>>
>> [MB] We had consensus in WGLC.  Your comments came well after WG last call
>> and after IETF LC.
>>
>>> We thought we had
>>> consensus, but people did not have the same understanding of this
>>> aspect of the draft.  (Ugh.)
>>
>>
>> This is a procedural issue, not a technical one.  I don't see any
>> objection to correcting the normative text if everyone who cares
>> agrees that the changes express what we intended.  (We should check
>> this point with the AD.)
>>
>> [MB] I do not see that we are changing any of the intended normative
>> behavior but rather fixing things that didn't quite reflect the
>> normative behavior as stated elsewhere (i.e., inconsistencies). [/MB]
>>
>> ==========
>>
>>> 5. In draft-ietf-sipcore-rfc4244bis-callflows-01, examples 3.6 and 3.7
>>> do not show the History-Info value in the final 200 response to the
>>> UAC.  This final value would be useful, in particular, because they
>>> give further examples of how proxies process History-Info.
>>
>>
>> I was mistaken here:  The final 200 response from the example.com
>> proxy to the UAC in these examples has the same History-Info as the
>> 200 response arriving at the example.com proxy, because there is no
>> History-Info information that the proxy knows that is not known to the
>> UAS that generated the 200 response.  Thus there is nothing
>> interesting to document.
>>
>> ==========
>>
>>> 6. Interestingly, despite the fact that there can be duplicate index
>>> values, when a request is received by a UAS, there is no ambiguity in
>>> the history when tracing *back* from the last hi-entry (the one that
>>> denotes the UAS).  This is because even if this UAS is "down one fork"
>>> from a forking non-supporting proxy, none of the hi-entries generated
>>> "down the other fork" will be present in the request the UAS sees.
>>>
>>> This is in contrast to the situation at the UAC, which may see
>>> hi-entries with duplicate indexes, and the interpretation of "rc",
>>> "mp", and "np" parameters can be ambiguous.
>>
>>
>> This is an interesting observation, but it does not require
>> documentation in the RFCs.
>>
>> ==========
>>
>>> 7. In example 3.6 message F6 in
>>> draft-ietf-sipcore-rfc4244bis-callflows-01, the History-Info is:
>>>
>>>     History-Info: <sip:[e-mail]>;index=1
>>>     History-Info: <sip:bob@192.0.2.5?Reason=SIP%3Bcause%3D302>;\
>>>                        index=1.1;rc=1
>>>     History-Info: <sip:[e-mail]>;index=1.2;mp=1
>>>     History-Info: <sip:carol@192.0.2.4?Reason=SIP%3Bcause%3D408>;\
>>>                        index=1.2.1;rc=1.2
>>>     History-Info: <sip:[e-mail];\
>>>                        target=sip:bob%40example.com;cause=408>;\
>>>                        index=1.3;mp=1.2
>>>     History-Info: <sip:vm@192.0.2.6;\
>>>                        target=sip:bob%40example.com;cause=408>;\
>>>                        index=1.3.1;rc=1.3
>>>
>>> This is what we intend, as it shows both where the index=1.3 URI came
>>> from (sip:[e-mail]) as well as why the index=1.3 fork was
>>> generated (because sip:[e-mail] failed).  But it points out
>>> that we need to improve the description in rfc4244bis section 5 of
>>> what the values of the "rc" (etc.) parameters are.  A naive reader
>>> might think "rc=1.2" in the 1.3 entry means that
>>> <sip:[e-mail];target=sip:bob%40example.com;cause=408> was
>>> generated as a contact for <sip:carol@192.0.2.4>.  Instead, it means
>>> that the 1.3 fork was generated *because* the 1.2 fork returned a
>>> response; it was generated *from* the index=1 URI.
>>>
>>> Actually, the real rules for interpreting "rc" (etc.) are not simple:
>>
>> [MB] The above is an example, thus the description is not complete. [/MB]
>>>
>>>
>>> 1) If the index-val in the param points to an entry with a Reason
>>> header-param whose value is "SIP;cause=3xx" (after removing
>>> escaping!), then:
>>> - the URI was one of the Contact values in the 3xx response
>>> - that response was why the new fork was generated.
>>>
>>> 2) If the index-val in the param points to the parent of this
>>> hi-entry, then:
>>> - the URI was generated from the URI of the parent hi-entry
>>> - the fork was not generated due to the response from any other fork.
>>>
>>> 3) If the index-val in the param points to an hi-entry that is not the
>>> parent, and that hi-entry does not contain a Reason header-param
>>> containing a 3xx status, then:
>>> - the URI was generated from the URI of the parent hi-entry
>>> - the fork was generated due to the response from the hi-entry with
>>> the specified index-val.
>>>
>>> And this doesn't match the section 5 definition of the value of "rc"
>>> (etc.), which is:
>>>
>>>           The "rc" header field parameter contains the value of the
>>>           hi-index in the hi-entry with an hi-targeted-to-uri that
>>>           reflects the Request-URI that was retargeted
>>
>>
>> In section 5, these paragraphs need to be revised:
>>
>>     o  hi-target-param: An optional parameter reflecting the mechanism by
>>        which the Request URI captured in the hi-targeted-to-uri in the
>>        History-Info header field value (hi-entry) was determined.  This
>>        parameter is either an "rc", "mp" or "np" header field parameter,
>>        which is interpreted as follows:
>>
>>           "rc": The hi-targeted-to-URI represents a change in Request-URI
>>           while the target user remains the same.  This occurs for
>>           example when user has multiple AoRs as an alias.  The "rc"
>>           header field parameter contains the value of the hi-index in
>>           the hi-entry with an hi-targeted-to-uri that reflects the
>>           Request-URI that was retargeted
>>
>>           "mp": The hi-targeted-to-URI represents a user other than the
>>           target user associated with the Request-URI in the incoming
>>           request that was retargeted.  This occurs when a request is
>>           statically or dynamically retargeted to another user
>>           represented by an AoR unassociated with the AoR of the original
>>           target user.  The "mp" header field parameter contains 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.
>>
>>           "np": The hi-targeted-to-URI represents that there was no
>>           change in Request-URI.  This would apply for example when a
>>           proxy merely forwards a request to a next hop proxy and loose
>>           routing is used.  The "np" header field parameter contains the
>>           value of the hi-index in the hi-entry with an hi-targeted-to-
>>           uri that reflects the Request-URI that was copied unchanged
>>           into the request represented by this hi-entry.  That value will
>>           usually be the hi-index of the parent hi-entry of this hi-
>>           entry.
>>
>> The revised paragraphs are:
>>
>> [MB] I don't agree with this proposal - that's way too much detail for
>> this section.  I believe that the normative
>> sections describe how/when you add the "rc" tag which should match
>> what you are describing in your new bullets.    I will note that this
>> section has been updated several times both adding more text and
>> reducing the text in this section.  What you have proposed for the
>> bullets below (i.e., the "rc", "mp" etc.) is some of the level of
>> detail we had previously (in the -02).   I believe the text you
>> suggest is application logic - note that items 2 & 4 describe the "rc"
>> scenarios and this wasn't intended to be comprehensive.  If you can
>> highlight what's missing in those 2 bullets, we can perhaps make some
>> changes there.   I will note if these suggestions had been made much
>> earlier in the process, it would have been much more helpful - much of
>> the text you mention has been in the document since around the -02.
>> We did several rounds of major edits while developing this document
>> both while it was an individual and as a WG document.  Note that this
>> document became a WG document literally 3 years ago.  It's quite
>> disruptive to be raising this issues at this stage. [/MB]
>>
>>     [This first paragraph is unchanged:]
>>     o  hi-target-param: An optional parameter reflecting the mechanism by
>>        which the Request URI captured in the hi-targeted-to-uri in the
>>        History-Info header field value (hi-entry) was determined.  This
>>        parameter is either an "rc", "mp" or "np" header field parameter,
>>        which is interpreted as follows:
>>
>>           "rc": The hi-targeted-to-URI represents a change in Request-URI
>>           while the target user remains the same.  This occurs for
>>           example when user has multiple AoRs as an alias or when
>>           forwarding the request to a registered contact of an AoR.
>>
>>           "mp": The hi-targeted-to-URI represents a user other than the
>>           target user associated with the Request-URI in the incoming
>>           request that was retargeted.  This occurs when a request is
>>           statically or dynamically retargeted to another user
>>           represented by an AoR unassociated with the AoR of the original
>>           target user.
>>
>>           "np": The hi-targeted-to-URI represents that there was no
>>           change in Request-URI.  This would apply for example when a
>>           proxy merely forwards a request to a next hop proxy and loose
>>           routing is used.  The "np" header field parameter contains the
>>           value of the hi-index in the parent hi-entry of this hi-entry.
>>
>>        If the index-val in the parameter points to the parent hi-entry of
>> this
>>        hi-entry, then:
>>        - the URI was generated from the URI of the parent hi-entry
>>        - the fork was not generated due to the response from any other
>> fork.
>>
>>        If the index-val in the parameter points to an hi-entry with a
>> Reason
>>        header value whose protocol is "SIP" and whose cause begins with
>> "3",
>>        then:
>>        - the URI was one of the Contact values in the 3xx response
>>        - the fork was generated due to the 3xx response from the hi-entry
>> with
>>        the specified index-val.
>>
>>        If the index-val in the param points to an hi-entry that is not the
>>        parent, and that hi-entry does not contain a Reason header value
>>        containing a SIP 3xx cause, then:
>>        - the URI was generated from the URI of the parent hi-entry
>>        - the fork was generated due to the response from the hi-entry with
>>        the specified index-val.
>>
>> ======================================================================
>>
>> I believe that is everything to be done.
>>
>> Dale
>> _______________________________________________
>> sipcore mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore