Re: [Sip] SIP Change Process

[Sean Olson <seancolson@yahoo.com>]

Sounds like the problem has been solved:
P-Supported, P-Require:

Seriously, relaxing the process to allow these option
tags in Supported: sounds like a good idea.

/sean

--- "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
wrote:
> 
> I believe that the SIP Change Process should be
> relaxed to allow
> non-chartered SIP extensions to define SIP option
> tags for use in Supported
> but but not in Require. 
> 
> Unless the aim of this draft is to prevent any
> non-chartered work from doing
> anything useful, this is an important distinction. 
> 
> I also see the current restriction (no option tags
> whatsoever) as actually
> counter-productive to the future state of the
> protocol - it simply forces
> authors to generate additional P-headers to indicate
> the ability to support
> an uncharter extension. 
> 
> Take as an example a typical P- compliant service
> such as media
> authorization. An entity may desire to know whther
> an access network
> supports media authorization before blindly placing
> a call with the P- media
> authorization header. Forcing networks to statically
> configure this
> knowledge is not desirable. Forcing authors to
> invent separate P- headers to
> indicate support for media authorization is not
> desirable. [I merely use
> this as an example; I am not saying that this needs
> to be added to that
> particular draft.]
> 
> Another argument: If someone writes a "P-Supported"
> extension draft then I
> beleive that this extension exactly falls into the
> restrictions of the SIP
> Change Process itself. The Supported header merely
> provides transparent
> information - exactly what P-headers were designed
> for. Thus, there should
> not be a restriction on the use of option tags
> within the normal Supported
> header. Require yes, Supported no.
> 
> As I said before, this eases migration of
> unchartered work group items into
> chartered items, that is, authors do not need to
> invent specific P-header
> mechanisms to cover the inability to use the normal
> Supported header.
> 
> That's my two cents anyway.
> 
> Cheers,
> 
> Robert.
> 
> _______________________________________________
> Sip mailing list 
> https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
> Protocol
> Use sip-implementors@cs.columbia.edu for questions
> on current sip
> Use sipping@ietf.org for new developments on the
> application of sip


=====
Sean Olson <seancolson@yahoo.com>

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip