Re: [sipcore] 4244bis-05: additional technical comments

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

Thanks for writing this, as both points you made lead me to realize
errors I was making!

> From: Hadriel Kaplan [[e-mail]]
> 
> 1) Section 10.3, page 19, says:
>    In the case that a SIP entity (intermediary or UAS) adds an hi-entry
>    on behalf of the previous hop, the hi-index MUST be set to 1.
> 
> Taken literally, this means when a request already marked with H-I
> entries happens to cross a legacy non-HI system, the next downstream
> element will add an additional H-I entry starting at 1 again.  Is that
> intentional/on-purpose??  At first I thought this was just an
> editorial mistake, but section 11, page 22, says :
> 
>    Gaps are possible if the request is forwarded through
>    intermediaries that do not support the History-info header field and
>    are reflected by the existence of multiple hi-entries with an index
>    of "1".
> 
> So a single SIP request can actually have multiple H-I trees with
> multiple root indexes of 1?  Wouldn't this make UAS logic code more
> complicated, because now the "mp=X" and "rc=X" index values are
> relative "X" values, scoped to within their particular tree, as
> opposed to being an absolute number for the whole H-I list?

I had mis-read this to mean that the receiving entity would construct
an H-I entry on behalf of the previous hop by adding a new H-I entry
with index "[whatever].1", that is, the entry the previous hop would
have added, had it forwarded to only one destination.

But that's not what the draft says, the draft says that the new index
is just "1".

Given the specifications, that new H-I entry must be the child of the
immediately preceeding H-I entry, so the H-I header is not ambiguous.
But it does destroy the principle that the three of H-I entries is
described simply by the index values.

> 2) Section 9.4, page 16 says:
>    When sending a response other than a 100, a SIP entity MUST include
>    all the cached hi-entries in the response, subject to the privacy
>    consideration in Section 10.1.2 with the following exception: If the
>    received request contained no hi-entries and there is no "histinfo"
>    option tag in the Supported header field, the SIP entity MUST NOT
>    include hi-entries in the response.
> 
> Note the "If the received request contained no hi-entries and...".  I
> don't know what having H-I entries has to do with it.  We have an
> option-tag for this purpose: histinfo.  If the option-tag is in the
> Supported, then you can send H-I entries in response.  Else not.  Even
> if the request contained H-I entries but no "histinfo" option tag, you
> can't send 'em back. (e.g., such would be the case if proxies added
> the entries but the UAC does not support it)

Hmm, I would be inclinded to agree with you, but, as written, the
draft solves a "problem" I was wondering about:

phone A (no H-I supt.) --> proxy B (H-I supt.) --> proxy C (H-I) --> phone D (H-I)

    Phone A does not insert H-I in the request.

    Proxy B inserts H-I in the request to proxy C:  One entry, index
    1, containing the original request-URI, and a second entry, index
    1.1, containing the request-URI it sends to proxy C.

    Proxy C inserts H-I in the request to phone D: index 1.1.1,
    containing the request-URI it sends to phone D.

    Phone D copies the H-I into its response -- because it received
    H-I in the request (which implies that some upstream entity can
    understand the H-I).

    Proxy C copies the H-I into its response, adding Reason to index
    1.1.1 -- because it received H-I in the request.

    Proxy B *does not* include H-I in its response.  The absence of
    "Supported: histinfo" and an incoming H-I in its request shows that no
    upstream entity understands H-I.

    Phone A receives a response without H-I, as it expected.

This arrangement satisfies these requirements:

1) No phone will receive H-I in a response if it does not support it.
Thus, no pre-H-I phone will receive a response that is unexpectedly
large.

2) Every H-I-aware entity will receive H-I information from every
upstream and downstream entity H-I-aware entity.

An implication of this is that "Supported: histinfo" is redundant and
can be eliminated from the protocol; a phone can indicate whether or
not it supports H-I by whether it includes a History-Info header.

Dale