Re: [sipcore] #2: Editorial: section 2 is really confusing

"Worley, Dale R (Dale)" <dworley@avaya.com> Thu, 02 September 2010 20:56 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 2CD503A6862 for <sipcore@core3.amsl.com>; Thu, 2 Sep 2010 13:56:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.438
X-Spam-Level:
X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 s-Vx93nxxFAc for <sipcore@core3.amsl.com>; Thu, 2 Sep 2010 13:56:01 -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 B24DA3A6886 for <sipcore@ietf.org>; Thu, 2 Sep 2010 13:54:12 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.56,309,1280721600"; d="scan'208";a="236042129"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Sep 2010 16:54:42 -0400
X-IronPort-AV: E=Sophos;i="4.56,309,1280721600"; d="scan'208";a="511666901"
Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Sep 2010 16:54:42 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.129]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 2 Sep 2010 16:54:41 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Date: Thu, 02 Sep 2010 16:54:41 -0400
Thread-Topic: [sipcore] #2: Editorial: section 2 is really confusing
Thread-Index: ActK3z38bZGepZ3XTc6Sd5fYwSdOjAAAN2iQ
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B21FFC79C11@DC-US1MBEX4.global.avaya.com>
References: <294E3E61-2DFE-4427-92F0-EDBDBE2888CC@acmepacket.com> <CD5674C3CD99574EBA7432465FC13C1B21FFC79BFD@DC-US1MBEX4.global.avaya.com> <AANLkTinnYZDcy7WLq-zeik65b9Cv-Q1Ck+-TW-c9_=KQ@mail.gmail.com> <CD5674C3CD99574EBA7432465FC13C1B21FFC79C02@DC-US1MBEX4.global.avaya.com>, <AANLkTimUSHbFmeVi2osjWcPE5ta28Dn-eW_giskpWzd1@mail.gmail.com> <CD5674C3CD99574EBA7432465FC13C1B21FFC79C0B@DC-US1MBEX4.global.avaya.com>, <0D2B6A34-F605-4F4B-BADD-E18CF0D1EC9D@acmepacket.com>
In-Reply-To: <0D2B6A34-F605-4F4B-BADD-E18CF0D1EC9D@acmepacket.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] #2: Editorial: section 2 is really confusing
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: Thu, 02 Sep 2010 20:56:02 -0000

________________________________________
From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Hadriel Kaplan [HKaplan@acmepacket.com]

The draft needs a re-write to use the terms, so that it will be easier to read.  Even if it's not in section 6.3.1's specific normative statements (though it should be), using the terms elsewhere in non-normative will make it easier to grok I think.

But first we need to agree on the terms.  Just using the word "retarget" again and again doesn't help imo, when we really mean different, specific sub-types of retargeting in different cases. (for the cases that matter)
_______________________________________________

My approach is to avoid using "those words" at all, because I see them as not being effectively defined.

But I think that everyone agrees that we must have a solid correspondence between:

- the paramters, tags, or values that distinguish the different cases (Currently "mp", "rc", and "[none]".)

- the correspondence between them and the specific situations that they indicate (Currently section 6.3.1.)

- the (carefully defined!) words we use to name those situations

In regard to "the words" themselves, of course we have to beware that almost all the words we'd like to use have been used heavily before, sometimes with careful definitions (e.g., "diversion" in PSTN) and sometimes rather sloppily (e.g., "retarget" in RFC 3261).  The latter may cause a conflict between "being clear" and "being compatible with previous usage".

Dale