Subject: [XCON] New "options" message in CCMP?

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 15 Jun 2010 19:28:42 +0200

Dear all,

we are refining the CCMP schema based both on our experience and on 
feedbacks received on the list. Apart from fixing some minor
nits which came out during the revision process, we thought that it 
might be useful to add to the set of protocol messages a new "options"
request which can be sent from a CCMP client to a CCMP server in order 
to retrieve general information about its capabilities (specifically
in terms of standard CCMP messages supported, plus potential extension 
messages understood by the server).
A potential (easy, yet long ;-)) extension to the current schema follows:

********************* BEGIN Options request message definition 
*************************
<xs:complexType name="ccmp-options-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
</xs:extension>
</xs:complexContent>
</xs:complexType>

   ********************** END options request definition ******************

********************* BEGIN options response message definition 
*************************
<xs:complexType name="ccmp-options-response-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-response-message-type">
<xs:sequence>
<xs:element ref="optionsResponse"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

<xs:element name="optionsResponse"
                 type="optionsResponseType" />

<xs:complexType name="optionsResponseType">
<xs:sequence>
<xs:element name="options"
                         type="options-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
                     minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

<xs:complexType name="options-type">
<xs:sequence>
<xs:element name="standard-message-list" 
type="standard-message-list-type" minOccurs="1"/>
<xs:element name="extended-message-list" 
type="extended-message-list-type" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
                     minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

<xs:complexType name="standard-message-list-type">
<xs:sequence>
<xs:element name="standard-message" type="standard-message-type" 
minOccurs="1" maxOccurs="10"/>
<xs:any namespace="##other" processContents="lax"
                     minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

<xs:complexType name="standard-message-type">
<xs:sequence>
<xs:element name="name" type="standard-message-name-type" minOccurs="1"/>
<xs:element name="schema-def" type="xs:string" />
<xs:element name="description" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
                     minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

<xs:simpleType name="standard-message-name-type">
<xs:restriction base="xs:token">
<xs:enumeration value="confsRequest"/>
<xs:enumeration value="confRequest"/>
<xs:enumeration value="blueprintsRequest"/>
<xs:enumeration value="blueprintRequest"/>
<xs:enumeration value="usersRequest"/>
<xs:enumeration value="userRequest"/>
<xs:enumeration value="sidebarsByValRequest"/>
<xs:enumeration value="sidebarByValRequest"/>
<xs:enumeration value="sidebarsByRefRequest"/>
<xs:enumeration value="sidebarByRefRequest"/>
</xs:restriction>
</xs:simpleType>

<xs:complexType name="extended-message-list-type">
<xs:sequence>
<xs:element name="extended-message" type="extended-message-type" 
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
                     minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

<xs:complexType name="extended-message-type">
<xs:sequence>
<xs:element name="name" type="xs:string" />
<xs:element name="schema-def" type="xs:string" />
<xs:element name="description" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
                     minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>

********************* END Options response message definition 
*************************

As it comes out from the above schema, an "options"  request message is 
a basic CCMP message. Coming to the response,
it can contain information about both standard (i.e. IETF-defined) CCMP 
messages and extension messages supported by the server.
In both cases, the response carries back a list of names of the 
supported (standard and extended) messages. Since all CCMP messages
can potentially contain XML elements not envisioned in the CCMP schema 
(due to the presence of <any> elements and attributes), a reference
to a proper schema definition specifying such new elements/attributes 
can also be sent back to the clients (in the <schema-ref> element).

What do you guys think of this further capability? Shall we add it to 
the new draft version? [Editor's note] We definitely find it useful ;-)!

Thanks for your feedback,

Simon

-- 

                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]
           http://www.comics.unina.it/simonpietro.romano

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/