Subject: [XCON] I-D Action:draft-ietf-xcon-ccmp-07.txt

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Tue, 1 Jun 2010 16:31:01 +0100

Hi Simon,
        Some of the changes I *think* we agreed on didn't make it in to
this draft. I have highlighed these in red below :-

  <xs:complexType name="ccmp-blueprints-request-message-type">
       <xs:complexContent>
           <xs:extension base="tns:ccmp-request-message-type">
               <xs:sequence>
                   <xs:element ref="blueprintsRequest" minOccurs="0" />
               </xs:sequence>
           </xs:extension>
       </xs:complexContent>
   </xs:complexType>

 <xs:complexType name="ccmp-confs-request-message-type">
       <xs:complexContent>
           <xs:extension base="tns:ccmp-request-message-type">
               <xs:sequence>

                   <xs:element ref="confsRequest" minOccurs="0"/>
               </xs:sequence>
           </xs:extension>
       </xs:complexContent>
   </xs:complexType>

 <xs:complexType name="ccmp-sidebarsByVal-request-message-type">
       <xs:complexContent>
           <xs:extension base="tns:ccmp-request-message-type">
               <xs:sequence>
                   <xs:element ref="sidebarsByValRequest"
minOccurs="0"/>
                </xs:sequence>
           </xs:extension>
       </xs:complexContent>
   </xs:complexType>

 <xs:complexType name="ccmp-sidebarsByRef-request-message-type">
        <xs:complexContent>
            <xs:extension base="tns:ccmp-request-message-type">
                <xs:sequence>
                    <xs:element ref="sidebarsByRefRequest" minOccurs="0"
/>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>

---

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Tue, 1 Jun 2010 16:37:52 +0100

Hi Simon,
    xsd namepsace is not defined , you need to change to xs istead
xs:simpleType name="response-codeType">
         <xsd:restriction base="xsd:positiveInteger">
                 <xsd:pattern value="[0-9][0-9][0-9]" />
         </xsd:restriction>

Barnes, et al.          Expires October 28, 2010               [Page 80]

  <outbind://57/#page-81> 
Internet-Draft                    CCMP                        April 2010

    </xs:simpleType>

---

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Tue, 1 Jun 2010 16:50:15 +0100

Hi Simon,
    The ccmp request extensions(see below) are generating a Unique
Particle Attribution violation. This is happening because
ccmp-request-message-type has an any also...
Maybe these extensions need a defined element which basically holds an
any...

 <!-- CCMP request extensions... -->
        <xs:complexType name="ccmp-extended-request-message-type">
          <xs:complexContent>
                <xs:extension base="tns:ccmp-request-message-type">
                  <xs:sequence>
                        <xs:any namespace="##other"
processContents="lax" minOccurs="0"
                          maxOccurs="unbounded" />
                  </xs:sequence>
                </xs:extension>
          </xs:complexContent>
        </xs:complexType>
 
  <!-- CCMP response extensions... -->
        <xs:complexType name="ccmp-extended-response-message-type">
          <xs:complexContent>
                <xs:extension base="tns:ccmp-response-message-type">
                  <xs:sequence>
                        <xs:any namespace="##other"
processContents="lax" minOccurs="0"
                          maxOccurs="unbounded" />
                  </xs:sequence>
                </xs:extension>
          </xs:complexContent>
        </xs:complexType>

---

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Wed, 2 Jun 2010 12:51:57 +0100

Hi Simon,
    I am wondering what is the most appropriate error code when a user
cannot be authenticated by the ccmp server? i.e. invalid user name or
password.
 
Around this area, we have the following error code defined:-
424 Authentication Required: User's authentication information missing
in a request to perform the requested operation. "subject" parameter
needed in the request. 
 
So we need another code like 'INVALID AUTHENTICATION' or we simply
change 424 to something like:-
 
424 Invalid Authentication : User's authentication information is
missing or invalid.
 
I prefer just having the one code i.e. renaming 424.
 
Regards
Sean

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 03 Jun 2010 17:24:12 +0200

Hi Sean,

right! This is the first of a series of minor errors we had already 
discovered and fixed in the upcoming version of the draft, which will be 
uploaded shortly. Thank you for mentioning it...I really appreciate the 
fact that someone else is playing with the specs ;-).

Cheers,

Simon

Il 01/06/2010 17.37, Duddy, Sean (Sean) ha scritto:
> _______________________________________________
> XCON mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xcon
>    

-- 
                             _\\|//_
                             ( 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~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 03 Jun 2010 17:31:57 +0200

Exactly. I modified the schema like we did for all other messages, 
namely the type "extended-request-message-type" extends the type 
"request-message-type" and contains the "extended-request", which is in 
turn of type "extended-request-type". Furthermore, inside the 
definitions of  both "extended-request-type" and 
"extended-response-type" we put an (optional) element called 
"extensionName". The modified schema now looks like the following:

*********************************************************************
<!-- CCMP request extensions -->
<xs:complexType name="ccmp-extended-request-message-type">
<xs:complexContent>
<xs:extension base="tns:ccmp-request-message-type">
<xs:sequence>
<xs:element ref="extendedRequest"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

<xs:element name="extendedRequest" type="extendedRequestType"/>

<xs:complexType name="extendedRequestType">
<xs:sequence>
<xs:element name="extensionName" type="xs:string" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
                            maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
*********************************************************************

Cheers,

Simon

Il 01/06/2010 17.50, Duddy, Sean (Sean) ha scritto:
> <xs:any namespace="##other" processContents="lax" minOccurs="0"
>                           maxOccurs="unbounded" />
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> <xs:any namespace="##other" processContents="lax" minOccurs="0"
>                           maxOccurs="unbounded" />
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
>
>

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 03 Jun 2010 17:34:25 +0200

Hi again,

> I prefer just having the one code i.e. renaming 424.

I totally agree. If no one else objects, I'll go for the "just one code" 
option and change the specs accordingly.

Simon

---

From: "Duddy, Sean (Sean)" <[email-masked]>
Date: Fri, 4 Jun 2010 15:20:27 +0100

Hi,
    I see there is a inconsistency between the constraints on the
request and response, see the highlighted item below:-
Is there a use case where a request would not have a confUserID?

   <xs:complexType abstract="true"
                  name="ccmp-request-message-type">
      <xs:sequence>
          <xs:element name="subject" type="subject-type"
                      minOccurs="0" maxOccurs="1" />
          <xs:element name="confUserID" type="xs:string"
                      minOccurs="0" maxOccurs="1" />
          <xs:element name="confObjID" type="xs:string"
                      minOccurs="0" maxOccurs="1" />
          <xs:element name="operation" type="operationType"
                      minOccurs="0" maxOccurs="1" />
          <xs:element name="conference-password" type="xs:string"
                      minOccurs="0" maxOccurs="1" />
         <xs:any namespace="##other" processContents="lax"
                 minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> 

<xs:complexType abstract="true" name="ccmp-response-message-type">
      <xs:sequence>
          <xs:element name="confUserID" type="xs:string"
                      minOccurs="1" maxOccurs="1" />
          <xs:element name="confObjID" type="xs:string"
                      minOccurs="0" maxOccurs="1" />
          <xs:element name="operation" minOccurs="0"
                      maxOccurs="1" />
          <xs:element ref="response-code" minOccurs="1"
                      maxOccurs="1" />
          <xs:element name="response-string" type="xs:string"
                      minOccurs="0" maxOccurs="1" />
          <xs:element name="version" type="xs:positiveInteger"
                      minOccurs="0" maxOccurs="1" />
          <xs:any namespace="##other" processContents="lax"
                      minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##any" processContents="lax"/>
  </xs:complexType>

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 10 Jun 2010 15:59:54 +0200

Hi Sean,

the use case you are referring to is explained in the draft. See 
sections 3.2 and 5.3.6 in draft-ietf-xcon-ccmp-07.

Do you agree this is a potential use case?

Simon

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 10 Jun 2010 16:02:00 +0200

Sean,

I would say it should have a minOccurs=0 (e.g. in retrieve messages...), 
but a maxOccurs=1, as you are suggesting.

What do you think?

Simon

Il 31/05/2010 16.47, Duddy, Sean (Sean) ha scritto:
> Hi Simon,
> 	Should the userInfo element of
>
>   <xs:complexType name="userRequestType">
>         <xs:sequence>
>             <xs:element name="userInfo"
>                         type="info:user-type" minOccurs="0" />
> have a minOccurs of 1 and a maxOccurs of 1? Is there an example of why
> it can be restricted to 1?
>
> Sean
>