The problem with mode

This is a list of what I heard were problems with mode that may  
deserve consideration.
the conceptual proposals are not designed to be either complete or  
detailed, but are based on principles applied to the noted problems.
They are also designed to provide functional equivalncy with no  
attempt to preserve the bits on the wire.

Given: Mode is designed to govern custom characteristics of a  
subscription.

Problem: Composition:
Mode is expressed as a single value attribute which defines a whole  
collection of potential behavioral characteristics.
Since it is a single value, it cannot be composed with other potential  
valuable extensions that could add additional functionality.
This forces or encourages a combinatorial explosion of modes as  
developers will be forced to define not only extensions by  
combinations of behaviors collected from different extensions.

conceptual proposal for resolution:
individual extensions may be expressed by their own QNames.
Multiple extensions may be specified thus composing behaviors of these  
extensions

Problem: scope:
The submission defines the Delivery element which contains both the  
NotifyTo EPR as well as the mode attribute
Earlier agreement in the WG created the format element as a child to  
the Subscription which moves those characteristics to be a child of  
the subscription.
EndTo is an EPR that is not contained in the delivery element and it  
seems reasonable that there may be behavioral aspects that might apply  
to the EndTo message as well as to the NotifyTo EPR.  It is also  
reasonable to expect that developers could want to extend the  
behaviors of these endpoints separately.
Arguments concerning dispatch of the Delivery element to a processing  
module seem strained if mode is defined in the delivery element and  
EndTo resides outside of that element.

conceptual proposal for resolution:
Extensions defined that modify the behavior of the subscription, such  
a lifetime, persistence, and subscription level quality of service,  
should reside contained within the subscription element.  Extensions  
that extend endpoint characteristics such as polled, reliability, or  
security should be contained within the epr they affect.
As for dispatch, it is a well known problem, that developers often  
have their own opinions as to the structure of processing code and  
methods exist for the gathering of elements for appropriate dispatch.

Problem: runtime negotiation:
The submission indicates a fault behavior that optionally returns a  
list of supported modes when the requested mode is not supported.   
Since this is optional it is unreliable.  Since there are a  
potentially large list of potential modes that may defined, the length  
of this list cam be large.  Problems associated with combinatorial  
explosion due to the lack of mode composability may make the list  
unmanageable.

conceptual proposal for resolution:
Eliminate the current optional faulting mechanism.
Define a new boolean attribute in subscription named strict
When strict is true, the subscription manager will create a  
subscription only when ALL of the requested extensions are supported.
If any of the requested extensions are not supported, a fault will be  
generated which will return the entire subscription element with  
extensions that are unknown removed.

When strict is false, the subscription manager creates the  
subscription with the all of the extensions that are supported  
omitting those it does not support. Subscription acknowledgement  
contains those extension elements that are supported omitting those  
that are unsupported.

Problem: concept of delivery mode:
conceptual proposal for resolution:
Delivery mode is the collective behavior defined by extensions  
supported by the subscription, NotifyTo EPR, and EndTo EPR.
It still exists, it has just been re-decorated.

Problem design-time determination of extension support:
conceptual proposal for resolution/large system runtime negotiation:
Define the framework for policy expressions with policy subjects  
Subscription, NotifyTo, and EndTo.