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

From: Christer Holmberg <[email-masked]>
Date: Sat, 29 Oct 2011 23:15:12 +0200

Hi Cullen,

> This started as something for a proxy to indicate what type of  things it could support that could show up in a Proxy-Require and allow a given proxy to indicate to downstream things an additional Proxy-Require level requirement. I thought that sounded like a reasonable idea but we needed to 
> nail down the details of what we were actually talking about.
>
> 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.

The requirements clearly say (or, are supposed to say) that the proxy that inserts the support indication must not make any assumptions that a receiver will understand the meaning of it. It is only an "I can do this" indication - NOT an "I have done this" or "I expect you to do this" indication. That has been the intention from day one :)

In that way it is exactly the same as when a UA inserts a feature tag in the Contact header field. The proposal is to allow entities that do not insert a Contact header field to do the same. Nothing more - nothing less.

I am happy to add whatever text is needed to make that even more clear.

Regards,

Christer

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

On Oct 28, 2011, at 2: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
>
> 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.
>
> -hadriel
>
>
> On Oct 28, 2011, at 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
>> _______________________________________________
>> sipcore mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore