[sipcore] Feature-Caps - Terminology [was: Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field)]

[Christer Holmberg <[e-mail]>]

Hi,

>>> Here are comments on the new version.
>>>
>>>  From the introduction:
>>>
>>>     This document defines a new SIP header field, Feature-Caps, that can
>>>    be used by entities to indicate support of features and capabilities,
>>>     in case they cannot use the Contact header field for that purpose.
>>>
>>> This is really loose!!!
>>> Its not limited to proxies. It could be any UA that "cannot use the
>>> Contact header field for that purpose". What constitutes a such a reason?
>>>
>>> The Definitions section has a very non-standard definition of Proxy:
>>>
>>>     Proxy: Within this specification, a "proxy" refers to an entity that
>>>    does not indicate supported features using the Contact header field.
>>>     Normally, however, entities that indicate support of features do not
>>>     act as pure proxies, as defined by RFC 3261, but rather contain
>>>     different levels of B2BUAs functionality.
>>>
>>> IMO Proxy should be defined only as it is in 3261.
>>
>> As I said when I submitted the draft, and which Hadriel also indicated, we DO need to sort out the terminology :)
>
> Consider these comments to be input to the terminology restructuring.
> Its something that we need to get right, because it goes to the heart of
> what this is about.

I agree.

The intention was not to keep the currently proposed terminology, but in order to be able to submit the draft start with something "familiar", and then work from there.


----------


>>> Section 4.1 says:
>>>
>>>     A UA MUST NOT, except when it acts as a SIP registrar, insert a
>>>     Feature-Caps header field in a SIP request or response.
>>>
>>> By this do you intend that a B2BUA/SBC cannot use this?
>>>
>>> Or are you drawing a fine line, where an element nominally acting as a
>>> proxy inserts this, even if it describes a feature that will require it
>>> starting to act as a B2BUA in the same dialog?
>>
>> The issue is not whether the entity is a proxy or a B2BUA, or a registrar.
>>
>> It's about an entity which is not "represented" by the Contact header field, or an entity which is not allowed (by SIP rules) to use the Contact header field.
>
> I like your characterization of the difference here better than what I have seen before.

And, in addition to the definition of the entity, we of course also need to decided what to call it :)


----------


>>> In section 6.2:
>>>
>>>     If a feature tag is inserted in a Feature-Caps header field of an
>>>     initial SIP request or response for a dialog, the feature associated
>>>     with the feature tag MUST be supported for the dialog, until the
>>>     dialog is terminated.
>>>
>>> Do you mean that it cannot be changed by subsequent signaling within the
>>> dialog? If Feature-Caps can be used by a 3pcc (b2bua) controller (can
>>> it?) then this limitation could break 3pcc transfers, where the
>>> transfer-target has different features.
>>
>> The limitation seems to be a left-over from when the draft used Record-Route.
>>
>> If needed, for Feature-Caps, we can always specify that entities must include it e.g. also in target refresh requests within a session.
>
> I think that is needed.

I'll note that down.


----------


>>> Section 8:
>>>
>>> Since this is using feature tags, it has to live with the IANA
>>> registration mechanism defined in 2506. I think that means, at best, you
>>> can require that certain material be included in the "Related standards
>>> or documents" that can optionally be included in a feature tag
>>> registration. That means it won't be possible to discern from a feature
>>> tag registration whether it applicable for use in Feature-Caps.
>>
>> I don't know remember whether the references are optional or not, but at least 3GPP has provided them for all feature tags.
>
> I checked - they are optional.
>
>> But, in general, I still think we can provide guidance and recommendations in the spec on what kind of information needs to be provided in the definition/registration.
>
> I guess you can say that a feature-tag can only be used in this way if
> the registration of the tag references a document that has some specific
> content. That would rule out all the existing ones, until their
> registration is updated.

I'll move this to the other thread, as it's not related to the entity terminology.

Regards,

Christer

        Thanks,
        Paul

> Regards,
>
> Christer
>
>
>
>
>
>
> On 10/28/11 6:09 AM, Christer Holmberg wrote:
>>
>> Hi,
>>
>> I've submitted a new version (-03) of draft-holmberg-sipcore-proxy-feature, which suggests a solution based on the proxy feature requirements.
>>
>> The MAJOR CHANGE, based on the list discussions, is that the mechanism now uses a new header field, Feature-Caps, rather than existing header fields (Record-Route, Path etc).
>>
>> I did not include the "SIP-URI alternative" at this point.
>>
>> We will also have to think about the "proxy" terminology, as it has been indicated that entities using the mechanism might not be pure proxies. But, I don't think that should prevent us from moving forward the the mechanism as such.
>>
>> Thanks to everyone who has provided feedback and input!
>>
>> Regards,
>>
>> Christer
>>
>
>