Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature

Paul Kyzivat <pkyzivat@cisco.com> Thu, 27 January 2011 17:12 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 3D06D28C141 for <sipcore@core3.amsl.com>; Thu, 27 Jan 2011 09:12:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.524
X-Spam-Level:
X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 y5wvUmlT19GQ for <sipcore@core3.amsl.com>; Thu, 27 Jan 2011 09:12:49 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4D95A28C13C for <sipcore@ietf.org>; Thu, 27 Jan 2011 09:12:49 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAB83QU1AZnwN/2dsb2JhbACkfXOgRZtIgneCWASFF4cQg0Q
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 27 Jan 2011 17:15:53 +0000
Received: from [10.86.250.39] (bxb-vpn3-551.cisco.com [10.86.250.39]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p0RHFquf011799; Thu, 27 Jan 2011 17:15:52 GMT
Message-ID: <4D41A848.1090304@cisco.com>
Date: Thu, 27 Jan 2011 12:15:52 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> <BDBFB6CE314EDF4CB80404CACAEFF5DE07C6C68C@XCH02DFW.rim.net>, <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B044@ESESSCMS0356.eemea.ericsson.se> <4D419713.7030000@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194427B199@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194427B199@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 version: draft-holmberg-sipcore-proxy-feature
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, 27 Jan 2011 17:12:50 -0000

On 1/27/2011 11:15 AM, Christer Holmberg wrote:

>> Another hurdle you're going to face is harmonizing your
>> proposal with RFC 5897. All three of your examples rely on
>> doing, just about as vigorously as possible, precisely what
>> RFC 5897 says not to do.
>
> Feature tags indicate support of a capability. EVERY feature tag does that - even if inserted in a Contact header field by a UA - and the feature tag specification needs to define the meaning of that capability.
>
> The important thing is that it cannot be assumed that other entities understand the meaning of the feature tag in order to progress a call (in such cases you will also need an option-tag, inserted in a Require/Proxy-Require header field).

There was also an extended discussion (battle?), around the time the 
callerprefs came out, about the validity of using feature-tags 
(capabilities) to identify arbitrary *services* where the service was to 
be defined in some external, potentially restricted document.

The crux of the argument was whether capabilities were orthogonal to one 
another or not. The concern was (and remains) that interoperability is 
severely limited if there are potentially many ways of specifying the 
same capability, as part of this service or that service.

(IIRC, one of the examples used was video calling, where somebody might 
describe a capability "video-phone" that implies a particular 
combination of audio and video. Two UAs that supported this might work 
well together, but somebody with a UA that supports exactly the same 
media types and *could* interoperate if connected, might fail to 
interoperate for lack of specifying the proper feature-tag.)

We run a risk of going through the same thing here. That is what 5897 
was about too.

	Thanks,
	Paul