Re: [RAI] Time for a feature tag?

"Spencer Dawkins" <spencer@wonderhamster.org> Tue, 04 May 2010 19:50 UTC

Return-Path: <spencer@wonderhamster.org>
X-Original-To: rai@core3.amsl.com
Delivered-To: rai@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B74628C5F2 for <rai@core3.amsl.com>; Tue, 4 May 2010 12:50:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.456
X-Spam-Level:
X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_40=-0.185, STOX_REPLY_TYPE=0.001]
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 7frakFOhkpSg for <rai@core3.amsl.com>; Tue, 4 May 2010 12:49:59 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 9988628C222 for <rai@ietf.org>; Tue, 4 May 2010 12:13:15 -0700 (PDT)
Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Lt2Ju-1NCZr146aw-011yig; Tue, 04 May 2010 15:13:01 -0400
Message-ID: <D65910763EF94825A54108FE7587FC9D@china.huawei.com>
From: Spencer Dawkins <spencer@wonderhamster.org>
To: Cullen Jennings <fluffy@cisco.com>, Dean Willis <dean.willis@softarmor.com>
References: <5436393912.955738117@softarmor.com> <D9570447-752B-4A36-BCB8-F25E4CAF6A09@cisco.com>
Date: Tue, 04 May 2010 14:12:44 -0500
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Provags-ID: V01U2FsdGVkX18YmO/4LmEiomYbpdk57rsXPCDKFYbxmS8bDx5 ZOFP+r1tSXo8nS+ix1v31IM8Cykaa1++Pf8s8DlA75vUuvp3Ok vmynV8zFA5YMJ+VXj9xHsK+td4FQOkXcbGkEBma7L8=
Cc: rai@ietf.org
Subject: Re: [RAI] Time for a feature tag?
X-BeenThere: rai@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Real-time Applications and Infrastructure \(RAI\)" <rai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rai>
List-Post: <mailto:rai@ietf.org>
List-Help: <mailto:rai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rai>, <mailto:rai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 May 2010 19:50:00 -0000

Cullen,

From: "Cullen Jennings" <fluffy@cisco.com>

> Didn't we have this conversation under the the subject DWIM vs DWIS ?
>
> On Apr 14, 2010, at 16:48 , Dean Willis wrote:
>
>> How about creating a new extension header field called Feature. This 
>> header field takes a list of feature values, and has the semantic that 
>> the message sender supports the named features. The feature namespace is 
>> entirely orthogonal to the option-tag namespace. No feature can change 
>> the basic state machine of SIP nor nullify a negotiated option. Further, 
>> nodes ising features MUST be able to fall back to basic SIP in the 
>> absence of mathching feature support in a correspondent node.
>>
>> Isn't that what you REALLY want?

I thought so, and note that the excellent 
https://datatracker.ietf.org/doc/draft-ietf-sipping-service-identification/ 
is in the RFC editor queue, in AUTH state...

Spencer