IETF Logo Mail Archive

Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case?

"Worley, Dale R (Dale)" <dworley@avaya.com> Fri, 19 November 2010 20:13 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 C4C0F3A68D0 for <sipcore@core3.amsl.com>; Fri, 19 Nov 2010 12:13:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.476
X-Spam-Level:
X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 RSBLiaOL9meP for <sipcore@core3.amsl.com>; Fri, 19 Nov 2010 12:13:20 -0800 (PST)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id C16623A689C for <sipcore@ietf.org>; Fri, 19 Nov 2010 12:13:19 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAN5o5kzGmAcF/2dsb2JhbACiYXGkQgKZJYVLBIRaiSk
X-IronPort-AV: E=Sophos;i="4.59,224,1288584000"; d="scan'208";a="219434483"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 Nov 2010 15:14:08 -0500
X-IronPort-AV: E=Sophos;i="4.59,225,1288584000"; d="scan'208";a="542835654"
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Nov 2010 15:14:08 -0500
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 19 Nov 2010 15:14:07 -0500
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Paul Kyzivat <pkyzivat@cisco.com>, Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Fri, 19 Nov 2010 15:11:20 -0500
Thread-Topic: [sipcore] Why doesn't 4244bis cover Marianne's use-case?
Thread-Index: AcuIHew+0kS/7W8vTce6TZxPUZQ7IQACAIl4
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B2202288A43@DC-US1MBEX4.global.avaya.com>
References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com> <CD5674C3CD99574EBA7432465FC13C1B2202288A40@DC-US1MBEX4.global.avaya.com> <4CE6BF03.1030307@cisco.com> <AANLkTimV-gmSbARFxxAiSeKMKukY=oL4d+2hn-EAZLAN@mail.gmail.com>, <4CE6CC6D.30103@cisco.com>
In-Reply-To: <4CE6CC6D.30103@cisco.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] Why doesn't 4244bis cover Marianne's use-case?
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, 19 Nov 2010 20:13:20 -0000

________________________________________
From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@cisco.com]

(I know I'm being legalistic here, but sometimes its necessary.)

[...]

- reword 4244bis so that a Reason header MAY be included (with suitable
   conditions - TBD) even if not received in a response, to cover
   Marianne's cases. (But this takes 4244bis beyond the scope it was
   intended to cover.)
_______________________________________________

Certainly in this situation, we'd better be legalistic, because there are so many ways that it could turn into a mess.

I prefer adding a suitable clause to 4244bis to allow the proxy to insert a Reason header for a URI that is redirected, as this is the clean way to handle the situation.  (The alternative is to synthesize an entry showing that the request was sent to a virtual redirection server, but that would make the H-I even longer.)  This is another aspect of the problem of documenting what the rules are for a consistent H-I header.

Dale

v2.23.0 | Report a Bug | By Email