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

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,
>>
>> 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
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>
>