[Sip] SIP Change Process

["Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>]

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