Subject: [sipcore] Questions about draft-ietf-sipcore-rfc4244bis-11.txt

From: [email-masked] (Dale R. Worley)
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:[email-masked]> (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.

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.

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.

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.

3. Due to the confusion discussed in #2, we have to consider whether
consensus was actually found in the WGLC.  We thought we had
consensus, but people did not have the same understanding of this
aspect of the draft.  (Ugh.)

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.

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.

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.

7. In example 3.6 message F6 in
draft-ietf-sipcore-rfc4244bis-callflows-01, the History-Info is:

   History-Info: <sip:[email-masked]>;index=1
   History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D302>;\
                      index=1.1;rc=1
   History-Info: <sip:[email-masked]>;index=1.2;mp=1
   History-Info: <sip:[email-masked]?Reason=SIP%3Bcause%3D408>;\
                      index=1.2.1;rc=1.2
   History-Info: <sip:[email-masked];\
                      target=sip:bob%40example.com;cause=408>;\
                      index=1.3;mp=1.2
   History-Info: <sip:[email-masked];\
                      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:[email-masked]) as well as why the index=1.3 fork was
generated (because sip:[email-masked] 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:[email-masked];target=sip:bob%40example.com;cause=408> was
generated as a contact for <sip:[email-masked]>.  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:

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

Dale