Re: [RAI] Time for a feature tag?

["Spencer Dawkins" <[e-mail]>]

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" <[e-mail]>
To: "Spencer Dawkins" <[e-mail]>
Cc: "Cullen Jennings" <[e-mail]>; "Dean Willis" 
<[e-mail]>; <[e-mail]>
Sent: Tuesday, May 04, 2010 2:58 PM
Subject: Re: [RAI] Time for a feature tag?


> On 5/4/10 14:12, May 4, Spencer Dawkins wrote:
>> Cullen,
>>
>> From: "Cullen Jennings" <[e-mail]>
>>
>>> 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...
>
> 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
>