Re: [sipcore] #29: B2BUAs passing H-I through?, #28 UAC adds initial HI

"Worley, Dale R (Dale)" <dworley@avaya.com> Fri, 17 September 2010 18:05 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A4DF3A68A4 for <sipcore@core3.amsl.com>; Fri, 17 Sep 2010 11:05:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.47
X-Spam-Level:
X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BYBfB14iA3b for <sipcore@core3.amsl.com>; Fri, 17 Sep 2010 11:05:52 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 990243A6869 for <sipcore@ietf.org>; Fri, 17 Sep 2010 11:05:46 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.56,383,1280721600"; d="scan'208";a="238505522"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Sep 2010 14:06:08 -0400
X-IronPort-AV: E=Sophos;i="4.56,383,1280721600"; d="scan'208";a="517515838"
Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Sep 2010 14:06:08 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.129]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Fri, 17 Sep 2010 14:06:07 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Fri, 17 Sep 2010 14:02:38 -0400
Thread-Topic: [sipcore] #29: B2BUAs passing H-I through?, #28 UAC adds initial HI
Thread-Index: ActRMiqHeQ7iAOlzQ3yD8DFPC5ltqwFYFjdu
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B21FFC79C63@DC-US1MBEX4.global.avaya.com>
References: <AANLkTi=SaY6hNPHCUU6d0mWmK7cZuL9py9z4Ui1Ym=Gt@mail.gmail.com>
In-Reply-To: <AANLkTi=SaY6hNPHCUU6d0mWmK7cZuL9py9z4Ui1Ym=Gt@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] #29: B2BUAs passing H-I through?, #28 UAC adds initial HI
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 17 Sep 2010 18:05:53 -0000

________________________________________
From: Mary Barnes [mary.ietf.barnes@gmail.com]

There is text that says that a UAC can add History-Info in section
4.1, which is the text Hadriel refers to in the original issue.
   "Normally, UACs are not expected to include a History-Info header
in an initial
   request as it is more of a Proxy function; the main reason it is
   allowed is for B2BUAs who are performing proxy-like functions such as
   routing."

Issue #29 suggests this should to be stated normatively (as well as
including this in the UAS section). It seems to me that we can make
that a MAY strength. It's not clear to me that we need to add anything
to the proxy section for B2BUAs as I really don't want to get into
trying to define B2BUA behavior beyond what is absolutely necessary in
this document.
_______________________________________

Well, strictly speaking, a B2BUA isn't a proxy.  The behavior we want to enable is part of the UAC function of the B2BUA.  But it seems to me that we want to enable this behavior normatively, and describe it much more clearly.  The current text mentions it only in passing, and while "there is only one thing that it could mean", that is not a good specification.

Dale