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

[Paul Kyzivat <[e-mail]>]

On 11/1/11 5:31 PM, Christer Holmberg wrote:
>
> 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 think Hadriel even had some proposed alternative wording).

>> 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, again, I totally agree that we need to use other wording than "proxy" and "UA", to make that clear :)

See my earlier comment.

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

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

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