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

[Christer Holmberg <[e-mail]>]

Hi,

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

Actually, the draft DOES talk about feature tags.

And, yes, we could start to talk about service-ids again, but that is a much wider topic, and is related to the usage of feature tags in general.

UAs are already allowed to indicate capabilities using feature tags, and the draft allows intermediaries to do the same.

But, of course, if one *requires* someone else to support something, option-tags should be used, but insertion of option-tags by intermediaries is outside the scope of the draft.

Regards,

Christer