[sipcore] 4244bis-05: additional technical comments

[Hadriel Kaplan <[e-mail]>]

Hi,
some more technical comments:

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?


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)

-hadriel