In both the term-level and my newly proposed agreement-level states, there is a modeling concern as to whether domain-specific or community-specific extensions of the state model are allowed. 1. [I do not like:] allowing arbitrary new states to replace existing states in the basic machine, e.g. the state machine can be in "no state" according to a basic client/observer who doesn't recognize extended states. 2. Allow "sub-states" which turn the basic state machine into a hyphergraph where specialized state transfers can happen "within" a generic state but transition rules between super states should be respected still. A. Encode sub-states as extensibility content within the basic state elements, meaning document structure follows the generic rules and extra content "flickers" within that structure. This approach can be applied recursively to extend extensions! B. Encode sub-states as sibling RPs to the basic state elements. This allows stacking/mixing of multiple state models but any consistency model between the various RPs is left unaddressed. C. Hybrid of (A) and (B) where basic non-extended content remains and a new extended variant is places alongside. This avoids the consistency issue of having to inspect both generic and specialized RPs, and also avoids requiring basic clients to filter or "project" extended states down to the base version they recognize. Do we have a clear consensus on which approach is advocated for WS-Agreement? I think extended states will be important both to address domain-specific things like "job states" as well as to compose with negotiation systems in the future. Thoughts? karl -- Karl Czajkowski karlcz@univa.com