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

[Christer Holmberg <[e-mail]>]

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.

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

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

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

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

Regards,

Christer