Re: [sipcore] Draft new: draft-holmberg-sipcore-proxy-feature [was: Feature-tags in the Path header field]

[Christer Holmberg <[e-mail]>]

Hi Dean,

>>>Specifically, Christer has identified a use case where it is important for other nodes to understand the options supported by a proxy in the
>>>registration path, when that proxy is reasonably expected to be on the request path for future requests using that registration.
>>>
>>>If, OTOH, we're really talking "feature tags" that refer to vendor-tree specific feature identification -- well, then we're back to the
>>>old service-identifier problem.
>>
>>Actually, the draft DOES talk about feature tags.
>
>So you mean "RFC 3840 media feature tags"? 

Correct.

>In your model, do they indicate that a particular feature is supported by the node, or do they indicate that a particular feature is being enforced by the node? 
>Or do they indicate a request for delivery of functionality by other nodes -- that is, do they inform other nodes so that routing decisions can be made?

Eventhough I guess one can make routing decissions based on whatever information, the basic purpose of a feature tag is NOT to indicate "routing policies" - it's to indicate that a particulare feature is suppored by the node that inserted the feature tag.

Regards,

Christer