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

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Nov 2011 13:25:43 -0400

On 10/31/11 2:36 PM, Christer Holmberg wrote:
>
> Hi,
>
>>> Since then it has slowly morphed into the type of DWIM vs DWIS mechanism that I thought we agreed we did not to do. Keep in mind any UA can
>>> act as an embedded proxy and this looks like the feature scheme that I thought was the roughly the core of the DWIM vs DWIS argument.
>>>
>>> Anyways, for any mechanisms of this sort, I will be strongly apposed unless the registration mechanism for new tags, features, options or whatever
>>> you call them is the same as it is for sip option tags. I have spoken at the mic several times in favor of  what Christer was presenting but it always had
>>> that property. This does not and I am strongly opposed to it. Given the previous conversation were in the other context, whatever consensus they
>>> may or may not have had does not seem to apply here. If the goal is simply to change what is required to register option tags, I'd be happy to have that conversation.
>>
>> Currently the draft mechanism is indicating RFC-3840-type feature-tags.  As such yes new values require RFCs published through IETF Consensus (IESG approval), as
>> opposed to standards track RFCs as required for option-tags.  I believe as a WG-draft we can choose whether tokens put into a new header are actual feature-tags,
>> or some new "capability-tags" with higher RFC approval status required.  And of course we can say what semantics such new capability-tags RFCs must define and be
>> constrained to.  I don't think any of those things prevent us from making it a WG draft do they?  I thought being a WG draft just meant the WG accepted the goal as a
>> milestone, had enough people willing to work on it, and thought the general direction of the draft's solution was right.
>>
>> Actually, its possible to define feature tags without any standards
>> action. See section 3.1.3 of RFC 2506. (It allows feature tags beginning
>> with "u." followed by a URI.)
>>
>> Its my impression that this is one of the things that 3gpp likes about
>> feature tags - they can define new ones without an ietf standards action.
>
> There are no 3GPP defined feature tags beginning with "u", and as far as I know 3GPP has (or, is in the progress of) registered all their feature tags with IANA.

OK, my mistake.

There is also a global tree (tags starting with g.) for which new values 
can be registered by expert review, without publication of an RFC. And 
3gpp has registered several of these.

> And, as you also indicated, we can specify what information a feature tag specification, and its associated IANA registration, needs to contain.

If we use feature tags, unless we require use of the "sip" tree, or 
define a new tree, I don't think we can specify what the specification 
includes, since the registration is defined by RFC 2506.

> Also, if you look at the use-cases behind this work, I think feature tags are very appropriate. We are talking about feature indications ("I can do this"). And, we are not talking about extensions to the SIP protocol, in
> which case I agree option-tags probably would be more suitable.

Frankly, IMO the adoption of feature tags for 3840 was a mistake, 
because the semantics of feature tags for callee caps / callerprefs 
largely disjoint from the intended original use of feature tags.

If the intent is to require a specification with particular properties, 
then we can do this better by defining a new namespace.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Nov 2011 16:22:53 -0400

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.

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?

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.

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.

	Thanks,
	Paul

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
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 01 Nov 2011 16:32:22 -0400

On 10/28/11 4:46 PM, Hadriel Kaplan wrote:
> Howdy,
> I've read this latest draft and I propose we make this a WG item.  I believe there has been strong consensus for this work, from even last year, but also from the following email thread from the SIPCORE Chairs asking for WG consensus:
> http://www.ietf.org/mail-archive/web/sipcore/current/msg04104.html

After discussion with the ADs, we decided to generate an item for the 
*requirements* document. And Christer mutated that document into the 
requirements doc that was then adopted as a WG draft.

> If this needs a new charter milestone, then I propose a new milestone be added for:
> "A mechanism to indicate proxy/B2BUA capabilities to both endpoints and other proxies/B2BUAs in the path of a SIP REGISTER transaction or a dialog-forming transaction".
>
> There may be some nits/details to argue over in the draft, but I think we can do that as a WG draft/item.
>
> As often asked for by WG Chairs when considering new milestones: I also volunteer to spend time/effort in contributing to the work item, and helping the authors by providing text if needed.

IMO there is still a lot of volatility around what the mechanism should 
look like. The new draft (with the ink still wet) is a substantial 
change from the prior one.

I'd like to see it stabilize a bit before moving to adopt it.
I appreciate your joining in the discussion. Till now its mostly been a 
dialog between me and Christer with an occasional shot from someone else.

	Thanks,
	Paul

> -hadriel
>
>
> On Oct 28, 2011, at 6:09 AM, Christer Holmberg wrote:
>
>>
>> Hi,
>>
>> _______________________________________________
>> sipcore mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sipcore
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 1 Nov 2011 22:31:18 +0100

Hi,

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

(I think Hadriel even had some proposed alternative wording).

-------------

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

And, again, I totally agree that we need to use other wording than "proxy" and "UA", to make that clear :)

-------------

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

-------------

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

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.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 1 Nov 2011 21:45:06 +0100

Hi,

> 3gpp has registered several of these.

Correct. I believe all 3GPP feature tags use the g.3gpp tree.

> includes, since the registration is defined by RFC 2506.

What is it then that is missing today? For example, alll the currently IANA registered g.3gpp feature tags DO contain a specification reference.

>> Also, if you look at the use-cases behind this work, I think feature tags are very appropriate. We are talking about feature
>> indications ("I can do this"). And, we are not talking about extensions to the SIP protocol, in which case I agree option-tags probably would be more suitable.
>

Again, the registered g.3gpp feature tags contain specification references.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Nov 2011 11:16:00 -0400

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

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Nov 2011 11:29:33 -0400

[trimming]

> What is it then that is missing today? For example, alll the currently IANA registered g.3gpp feature tags DO contain a specification reference.

We can't easily (without ammending 2506) change what is required to 
register a feature tag. The document references are optional, and there 
is no required content for referenced documents.

I think its probably possible to craft the normative requirements for a 
new usage of feature-tags (i.e. in Feature-Caps) to restrict usage to 
feature tags that have a referenced document with some specific content.

What that wouldn't do is normatively prohibit the use of those new 
feature tags in other places, such as called out in 3840/3841. To do 
that we would have to revise 3840/3841.

	Thanks,
	Paul