Subject: [sipcore] Feature-Caps: feature tag syntax [was: draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature]

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Oct 2011 23:04:12 +0200

Hi,

>>> I also think we still should discuss what namespace these "features"
>>> come from. You had originally proposed that these be feature tags as
>>> defined in 3840, but with a twist that the meaning of features be
>>> different for proxies than for UAs. I guess the reason for proposing
>>> feature tags was that the mechanism for them already exists, and a
>>> certain similarity of attaching them to a URI.
>>
>> The feature tag concept is not defined in RFC 3840. RFC 3840 defines a SIP specific feature tag syntax, and how SIP UAs use feature tags to indicate capabilities.
>
> Yes, 3840 borrowed the underlying feature tag mechanism and registry.
> (IMO it was a poor fit, but its too late to argue over it.)
> For practical purposes the registry of sip features is distinct. (They
> all start with "sip." except for some grandfathered ones.)
> And as you say, the syntax for representing them is modified.
>
> All of this was built around the need to provide a way of "matching"
> preferences against capabilities.
>
>> The new mechanism would define how SIP "proxies" use feature tag to indicate capabilties.
>
> AFAIK you have no intent to extend 3841 to do matching on
> proxy-features. (Or do you?)
>
> If not, there is no need for a representation that supports the matching
> mechanics of 3841. (Which is already far too arcane.)

The intention is not to extend 3841.

I think the current draft says that, but if it doesn't I will add text to clarify it.

>> But, I agree that the semantics may vary depending on whether a UA or a "proxy" inserts the feature tag, and the 
>> feature tag specification would have to handle that.
>
> If we use the existing feature tag registry for this new use, either the
> namespace will need to be changed (e.g. use something other than "sip."
> as a prefix), or else feature tag specifications that follow 3840 will
> only apply to UAs, and those that follow this new draft will only apply
> to proxies, or will contain separate sub-specifications for UA and proxy
> behavior. So in reality there will be different namespaces for UAs and
> proxies. And in practice there will probably be distinct names as well.
>
> So the only advantage of using the feature tag type and registry is to
> avoid defining a new registry.
>
>>> That was already a bit of a stretch because the semantics were a bit
>>> different. With the new mechanism being defined its a bit more of a
>>> stretch. Also, the syntax of values for feature tags is coupled to the
>>> callerpref matching algorithm. I have heard no suggestion of a matching
>>> algorithm for proxy features. (Though your concern for detecting the
>>> shared appearance of multiple features might imply one.)
>>
>> I am not sure I understand how the syntax is coupled to the callerpref maching mechanism.
>
> See above. The syntax of values is defined so that it can be mapped onto
> feature tag predicates, so that those can be used to define matching in
> 3841.

That may be true, but I don't see a reason why we should invent something new just because of that. I don't think it would be "overkill" to use the existing syntax, even if we won't use it for matching. The syntax has a very good tree structure, which I think is very clear and useful.

Also, if I define a feature that can be supported both by a UA and a "proxy", I think it's good if I can use the same feature tag syntax and value - EVEN if I may have to register them in separate registries.

Then, whether we'll need "*" or not I guess depends on the outcome of the other discussion, but that is more related to the header field syntax rather than the feature tag syntax.

Regards,

Christer