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

[Dean Willis <[e-mail]>]

On Sep 27, 2010, at 9:46 AM, Paul Kyzivat wrote:

> [as chair]
>
> To all sipcore participants:
>
> Christer has been looking for a way to accomplish a particular  
> function that 3gpp wants. This proposal seems a plausible way to do  
> that. But it is of necessity defining a more general mechanism.
>
> I'd really appreciate comments from others (including people in no  
> way involved with 3gpp) regarding this mechanism. For instance, do  
> you consider the semantics to be well defined? Do you see need for  
> more about security implications?
>

I think it's important to note that we're talking about a way of  
advertising "option tags" -- the same option tags that theoretically  
get added to the "Supported" headers in lots of messages, and that the  
"Options" request was particularly designed to collect.

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.

--
Dean