Re: [RAI] Time for a feature tag?

[Adam Roach <[e-mail]>]

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