Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field]

Paul Kyzivat <pkyzivat@cisco.com> Mon, 27 September 2010 14:46 UTC

Return-Path: <pkyzivat@cisco.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 C0DEE3A6D4A for <sipcore@core3.amsl.com>; Mon, 27 Sep 2010 07:46:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.505
X-Spam-Level:
X-Spam-Status: No, score=-110.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 hpKiYmgYfRqu for <sipcore@core3.amsl.com>; Mon, 27 Sep 2010 07:46:19 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1BC883A6D47 for <sipcore@ietf.org>; Mon, 27 Sep 2010 07:46:19 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAMpKoExAZnwM/2dsb2JhbACiM3GqZJwhhUQEijqCfg
X-IronPort-AV: E=Sophos;i="4.57,243,1283731200"; d="scan'208";a="164144001"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 27 Sep 2010 14:46:58 +0000
Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o8REkvDt005360; Mon, 27 Sep 2010 14:46:58 GMT
Message-ID: <4CA0AE61.7060003@cisco.com>
Date: Mon, 27 Sep 2010 10:46:57 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <7F2072F1E0DE894DA4B517B93C6A058501703422@ESESSCMS0356.eemea.ericsson.se> <4C936714.2040808@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501703523@ESESSCMS0356.eemea.ericsson.se>, <4C936E79.3070906@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8B@ESESSCMS0356.eemea.ericsson.se>, <4C938ED5.10507@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8E@ESESSCMS0356.eemea.ericsson.se>, <4C93E4DE.9070802@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA92@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058501769F3A@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058501769F3A@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field]
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: Mon, 27 Sep 2010 14:46:20 -0000

[as chair]

To all sipcore participants:

Christer has been looking for a way to accomplish a particular function 
that 3gpp wants. This proposal seems a plausible way to do that. But it 
is of necessity defining a more general mechanism.

I'd really appreciate comments from others (including people in no way 
involved with 3gpp) regarding this mechanism. For instance, do you 
consider the semantics to be well defined? Do you see need for more 
about security implications?

How many would find this useful to have?

	Thanks,
	Paul

On 9/24/2010 7:04 AM, Christer Holmberg wrote:
>
> Hi,
>
> I've submitted a draft, which extends the rr-param rule, allowing proxies to indicate supported features using feature tags in Path, Record-Route etc.
>
> The draft can also be found at: http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore-proxy-feature-00.txt
>
> As I indicated earlier on the list, and as you can read in the draft, there is a 3GPP use-case where we believe the mechanism could be used. But, there is nothing 3GPP specific about the mechanism as such.
>
> Regards,
>
> Christer