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

"Worley, Dale R (Dale)" <dworley@avaya.com> Thu, 02 September 2010 19:15 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 819B43A699A for <sipcore@core3.amsl.com>; Thu, 2 Sep 2010 12:15:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.423
X-Spam-Level:
X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 eawbi5MGq4hK for <sipcore@core3.amsl.com>; Thu, 2 Sep 2010 12:15:47 -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 12A623A6962 for <sipcore@ietf.org>; Thu, 2 Sep 2010 12:15:47 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.56,309,1280721600"; d="scan'208";a="236025298"
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 15:16:16 -0400
X-IronPort-AV: E=Sophos;i="4.56,309,1280721600"; d="scan'208";a="511627404"
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; 02 Sep 2010 15:16:16 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.129]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 2 Sep 2010 15:16:15 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Thu, 02 Sep 2010 15:15:54 -0400
Thread-Topic: [sipcore] #2: Editorial: section 2 is really confusing
Thread-Index: ActJREba6aTEDRZpTJaopoJravq3rgBjvyq7
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B21FFC79C0B@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>
In-Reply-To: <AANLkTimUSHbFmeVi2osjWcPE5ta28Dn-eW_giskpWzd1@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>, Hadriel Kaplan <HKaplan@acmepacket.com>
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 19:15:48 -0000

From: Mary Barnes [mary.ietf.barnes@gmail.com]
> On Tue, Aug 31, 2010 at 1:36 PM, Worley, Dale R (Dale)
> <dworley@avaya.com> wrote:
> > From: Mary Barnes [mary.ietf.barnes@gmail.com]
> >
> > > I'm of the
> > > mindset right now that we should resolve all the other editorial
> > > issues and see if being more precise with the current definitions
> > > doesn't help and just live with the ambiguity as we've lived with it
> > > for other terms.  The important aspect is what happens with the
> > > protocol and I think it's more important to get the normative text
> > > correct.
> >
> > It seems to me that the definitions of "retargeting", "redirecting",
> > etc. (with the possible exception of "diversion") are not clear and
> > have never been clear.  Up until 4244bis, this hasn't mattered.  But
> > in 4244bis these allegedly distinct operations cause different things
> > to go on the wire, so we have to make the definitions unambiguous.
> 
> The intent is that the tags (or lack thereof) are what adds the
> clarification.  There's only so much we can do to not avoid conflict
> with other terms.  IF we were rewriting RFC 3261, then certainly, we
> could resolve this issue.  My suggestion is that we clean up all the
> other issues, etc. that folks have highlighted and then we'll see
> where we are. It might become more obvious (to me at least) how best
> to use the terms as I'm in the middle of the edits.

In regard to "retarget", "forward", "rerouting", "contact routing",
and even "diversion", we should note that defining them (in any
manner) is not necessary for this work to progress.  If those terms
were to have any ultimate relevance, they would appear in the text
that specifies when "rc" and "mp" are to be use, which is:

   6.3.1

   o  "rc": The Request-URI is a contact that is bound to an AOR in an
      abstract location service.  The AOR-to-contact binding has been
      placed into the location service by a SIP Registrar that received
      a SIP REGISTER request.

   o  "mp": The Request-URI is a URI that represents another user.  This
      occurs when a request is to be statically or dynamically
      retargeted to another user.

And we may disregard the second sentence of the second case, as it
describes an example of the case; the specification is the first
sentence.

Once that sentence is disregarded, it's clear that "retarget" et
al. have no normative appearance in the document.

Dale