Subject: Re: [RAI] Time for a feature tag?

From: Cullen Jennings <[email-masked]>
Date: Tue, 4 May 2010 08:48:15 -0600

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?
> 
> --
> Dean _______________________________________________
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 4 May 2010 14:12:44 -0500

Cullen,

From: "Cullen Jennings" <[email-masked]>

>> 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.
>>

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

---

From: Adam Roach <[email-masked]>
Date: Tue, 04 May 2010 14:58:30 -0500

On 5/4/10 14:12, May 4, Spencer Dawkins wrote:
>>> 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.
>>>

That's not quite it. The service-identification document is an 
informational document that highlights the perils of what Dean has 
suggested (presumably with his tongue planted firmly in his cheek). 
Here's the executive summary, taken from the document itself:

    [T]his document concludes that declarative service
    identification - the process by which a user agent inserts a moniker
    into a message that defines the desired service, separate from
    explicit and well-defined protocol mechanisms, is harmful.

Section 5 does a good job of talking about how to properly identify a 
service -- and, more importantly, how not to.

/a

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 5 May 2010 05:00:05 -0500

Hi, Adam,

I'm sorry, I may not have been clear. My "I thought so" was in response to 
Cullen's "Didn't we have this conversation", not to Dean's "Isn't that what 
you really want?", which was, of course, the immediately-prior question most 
likely to be associated with an answer.

But thanks for the helpful summation, which I should have included in my 
response, if I'd been trying to be more helpful.

Thanks,

Spencer

----- Original Message ----- 
From: "Adam Roach" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>
Cc: "Cullen Jennings" <[email-masked]>; "Dean Willis" 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, May 04, 2010 2:58 PM
Subject: Re: [RAI] Time for a feature tag?

>>>> 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.
>>>>
> suggested (presumably with his tongue planted firmly in his cheek). Here's 
> the executive summary, taken from the document itself:
>