[sipcore] 4244bis-05: additional technical comments

Hadriel Kaplan <HKaplan@acmepacket.com> Wed, 15 June 2011 20:15 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3176B9E8026 for <sipcore@ietfa.amsl.com>; Wed, 15 Jun 2011 13:15:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.536
X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id mzx-b8H0fMtJ for <sipcore@ietfa.amsl.com>; Wed, 15 Jun 2011 13:15:29 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com []) by ietfa.amsl.com (Postfix) with ESMTP id 7DF9E9E800F for <sipcore@ietf.org>; Wed, 15 Jun 2011 13:15:29 -0700 (PDT)
Received: from mail.acmepacket.com ( by etmail.acmepacket.com ( with Microsoft SMTP Server (TLS) id; Wed, 15 Jun 2011 16:15:28 -0400
Received: from mailbox1.acmepacket.com ([]) by mail ([]) with mapi; Wed, 15 Jun 2011 16:15:28 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: "sipcore@ietf.org WG" <sipcore@ietf.org>
Date: Wed, 15 Jun 2011 16:15:27 -0400
Thread-Topic: 4244bis-05: additional technical comments
Thread-Index: AcwrmPf5m+md7tDbQPehEG90d3slFA==
Message-ID: <3B2A8F8E-4255-4156-B882-BF68F4046F3D@acmepacket.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAUA=
Cc: "draft-ietf-sipcore-rfc4244bis@tools.ietf.org" <draft-ietf-sipcore-rfc4244bis@tools.ietf.org>
Subject: [sipcore] 4244bis-05: additional technical comments
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jun 2011 20:15:30 -0000

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)