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

Dean Willis <dean.willis@softarmor.com> Fri, 22 October 2010 20:52 UTC

Return-Path: <dean.willis@softarmor.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 AADF63A68BA for <sipcore@core3.amsl.com>; Fri, 22 Oct 2010 13:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.912
X-Spam-Level:
X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[AWL=0.687, 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 6uCDZ0-qCJor for <sipcore@core3.amsl.com>; Fri, 22 Oct 2010 13:52:18 -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 42F9A3A6805 for <sipcore@ietf.org>; Fri, 22 Oct 2010 13:52:18 -0700 (PDT)
Received: by yxp4 with SMTP id 4so1106672yxp.31 for <sipcore@ietf.org>; Fri, 22 Oct 2010 13:53:56 -0700 (PDT)
Received: by 10.150.211.2 with SMTP id j2mr6944504ybg.201.1287780835184; Fri, 22 Oct 2010 13:53:55 -0700 (PDT)
Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) by mx.google.com with ESMTPS id j27sm2724797yha.30.2010.10.22.13.53.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 22 Oct 2010 13:53:53 -0700 (PDT)
Message-Id: <F083A50B-7E2C-48FF-B983-C50D458144BE@softarmor.com>
From: Dean Willis <dean.willis@softarmor.com>
To: Paul Kyzivat <pkyzivat@cisco.com>
In-Reply-To: <4CA0AE61.7060003@cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 22 Oct 2010 15:53:51 -0500
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> <4CA0AE61.7060003@cisco.com>
X-Mailer: Apple Mail (2.936)
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: Fri, 22 Oct 2010 20:52:19 -0000

On Sep 27, 2010, at 9:46 AM, Paul Kyzivat wrote:

> [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?
>

I think it's important to note that we're talking about a way of  
advertising "option tags" -- the same option tags that theoretically  
get added to the "Supported" headers in lots of messages, and that the  
"Options" request was particularly designed to collect.

Specifically, Christer has identified a use case where it is important  
for other nodes to understand the options supported by a proxy in the  
registration path, when that proxy is reasonably expected to be on the  
request path for future requests using that registration.

If, OTOH, we're really talking "feature tags" that refer to vendor- 
tree specific feature identification -- well, then we're back to the  
old service-identifier problem.

--
Dean