Re: [sipcore] 4244bis-05: Semantics of History-Info

["Worley, Dale R (Dale)" <[e-mail]>]

One advantage to writing this description is that it tends to throw into
sharp relief the technical issues that haven't been solidified, either because
one discovers that some aspect of the semantics can't be described
unambiguously, or because one of the "operational" sections doesn't
fit with the semantics.

The current version of the draft is considerably clearer than the previous
versions, which made it much easier to write the semantics.

In this vein, following is a list of technical issues, most of which are the
parenthesized comments in my first draft of the semantics.


[There are complexities if the UAC does not support History-Info, but
downstream entities do, particularly if a first History-Info is added
on two different forks -- both forks have hi-entries with index "1".]

In the current state of the draft, this isn't a problem, because the UAC
didn't include "Supported: histinfo", so no responses contain History-Info,
and so no History-Info headers from one "island" will ever collide with those
of another "island".

But it seems like it would be useful to allow a proxy to insert "Supported: histinfo"
into an outgoing request, as long as it purged the History-Info from any response
it sent upstream.


[Suppose the UAC sends
"History-Info: AOR;index=1", and a non-History-Info-supporting entity forks it
to two destinations, UAS A and UAS B, both of which support
History-Info.  UAS A normalizes the request to "History-Info:
AOR;index=1, UAS-A;index=1.1" while UAS B normalizes the request to
"History-Info: AOR;index=1, UAS-B;index=1.1".]

These two normalized requests violate the rule that everybody expects
to be satisfied, viz., that all hi-entries in the entire forking
structure with the same index represent the same request.  As a
result, the responses from the two UASs cannot be merged in any useful
way.  Since both UASs could send 1xx responses containing History-Info,
the UAC can see two different hi-entries with index=1.1.


In section 9.1 are the rules to help in the case where a H-I-supporting entity
receives a request from a non-H-I-supporting entity.  As written, it only discusses
the case where there is already an H-I header in the request.  Strictly speaking,
the algorithm given faults if there is no H-I header present.  But ISTR that we
intended that in this case, an hi-entry with index=1 should be inserted by the receiving
entity.


[Also need to take care of the case where the UAC generates several
requests as forks of a theoretical ancestral request, as is used in
draft-ietf-bliss-call-completion.  It seems like they should have
index=1, index=2, index=3, etc.  But this does mean that the "tree" now
has an invisible root node whose index is the empty string of integers.]


[What if a mapping is done in some other manner?  How do we record the
index-val of the value from which the new Request-URI was derived?]

We still need to decide what do to about mappings that do not qualify for
either "rc" or "mp".



[Need to detail exactly what can be included in a Reason header in an
hi-targeted-to-uri.  It seems that
Reason may contain any non-2xx final SIP response code, as well as any
non-SIP response codes -- see
draft-jesske-dispatch-update3326-reason-responses.  2xx response codes
seem to be implicit in that the hi-entry is seen in a non-descendant
request or a response, but no SIP Response value is present.  Do we
want this irregularity for 2xx?  Or is this necessary for backward compatibility?]

Do we want to prescribe that reason texts be encoded into the Reason header?
For SIP response codes, this seems pointless, except for error situations where
the response-text might have been customized.  For other protocols, the reason-text
might be more important.  But none of the examples in the draft
shows reason-text, and I expect that people will not bother to implement it
unless it is explicitly required.


[If an entity desires or is required to apply Reason
or Privacy to an hi-entry containing a tel: URI, MUST it convert it
to a sip: URI, and then proceed?  If so, it would be better if that was stated
explicitly.  OTOH, it's possible that the step of applying the header is skipped
for tel: URIs.]

Dale