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

Mary Barnes <mary.ietf.barnes@gmail.com> Wed, 01 September 2010 15:20 UTC

Return-Path: <mary.ietf.barnes@gmail.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 F09AE3A6927 for <sipcore@core3.amsl.com>; Wed, 1 Sep 2010 08:20:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.478
X-Spam-Level:
X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 VQcdwc-8-fY6 for <sipcore@core3.amsl.com>; Wed, 1 Sep 2010 08:20:00 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id EBAF03A6816 for <sipcore@ietf.org>; Wed, 1 Sep 2010 08:19:59 -0700 (PDT)
Received: by yxl31 with SMTP id 31so1986930yxl.31 for <sipcore@ietf.org>; Wed, 01 Sep 2010 08:20:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=f5K3bRW5ulLE2s5LetSVBZYLk30049TpIQvHykrADg0=; b=NXfAwXonUKC1BBItcojspf4VScyw+GBBqqC+aU/x54yynZUV+4pJGK6PXV/yd2INds u0PRRkJaAkG2xlh/mXI3w+CJIe48xpg4rCrsMlqvSjK6gDXsNCd8N7INj7hlffHn/Mlf UZByx4ELWecYpxkpdaGoGcuDoHZF58MlfWOeQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=OJC/MUrppqG0tRSXoja4VbGHUP59dGVXjflg668Pq/pNTl0tiVCMLDVwDqZFkv4pEJ 5Fnl1GR+E1iKvqiqMnxzw+V9PlszovgwtlV7f2k6bGJVWcKtQFxK3SMdWf+ChCQK56Mn EDAUV/3r8t/YKbU6ZDRiMVVqsK3d9gpNRkkF4=
MIME-Version: 1.0
Received: by 10.100.6.11 with SMTP id 11mr8479931anf.33.1283354430108; Wed, 01 Sep 2010 08:20:30 -0700 (PDT)
Received: by 10.100.16.23 with HTTP; Wed, 1 Sep 2010 08:20:30 -0700 (PDT)
In-Reply-To: <3A1175B1-93F3-440E-9965-5073BB426D8B@acmepacket.com>
References: <294E3E61-2DFE-4427-92F0-EDBDBE2888CC@acmepacket.com> <CD5674C3CD99574EBA7432465FC13C1B21FFC79BFD@DC-US1MBEX4.global.avaya.com> <EDC0A1AE77C57744B664A310A0B23AE214D298AE@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <3A1175B1-93F3-440E-9965-5073BB426D8B@acmepacket.com>
Date: Wed, 01 Sep 2010 10:20:30 -0500
Message-ID: <AANLkTikcQQbjxzUD4qcXG=FDbv3MbhFJya=0bZp5oLkk@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "Worley, Dale R (Dale)" <dworley@avaya.com>, "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>, "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: Wed, 01 Sep 2010 15:20:02 -0000

We had a couple more tags in previous versions of the individual
draft, but we removed those for the sake of simplicity and addressing
the known use cases. If we think the tags we have are not sufficient,
we can revisit (I personally liked have very unique tags even if the
end behavior for the tags was the same).

Mary.

On Wed, Sep 1, 2010 at 9:50 AM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:
>
> Oh, excellent point.  In fact, mapping in the freephone sense isn't really the same "kind" as mapping in the call-forwarding sense, and will make it neigh impossible to distinguish at the UAS.  How will a UAS actually be able to tell apart diversions from others? (for example, to interwork to Diversion or to ISDN)
>
> Perhaps what we really need is a specific tag for actual diverting - for the case of changing the identity of the target such that the new identity has no inherent relation to the previous target, for example with a "dv" param; whereas the freephone case the new target is much closer to "mapping" in the common english sense and would use a "mp".  No?
>
> -hadriel
>
>
> On Sep 1, 2010, at 10:01 AM, DRAGE, Keith (Keith) wrote:
>
>> I prefer not to use the term "diversion" because there is a well defined set of ISDN diversion services, and while the use of History-Info does encompass equivalents of such services, it encompasses much more.
>>
>> Changing the target to a new Request-URI may encompass diversion (in the ISDN sense), but it could also encompass a number of other cases, including freephone and number portability.
>>
>> regards
>>
>> Keith
>>>
>
>