Subject: RE: [XCON] Data Model

From: "Oscar Novo \(JO/LMF\)" <[email-masked]>
Date: Wed, 21 Jun 2006 12:51:55 +0200

Thanks Srivatsa and Sean for your comments. We have included some of your comments in the next version of the draft that I will submit on Monday. If anybody has more comments about the data model draft, please send to me all of them before monday.

One thing that I would like to remark and reading your comments I'm not sure you've understood this, is that this draft defines an Extensible Markup Language (XML) Schema that represents the common conference information in a conference system. It doesn't mean that all this information have to be defined in a conference system. Only the information that the conference system supports will be defined in the data model. How is this information define in the server is out of the scope of our draft and should be defined in the conference control protocol or, more generally, in the framework.
In the following paragraph I try to answer all your questions and fix all the errors you´ve found in the draft. 

Thank you very much for your review.

Oscar

------------------

Here are comments for the data model
draft-ietf-xcon-common-data-model-00. This email incorporates comments from Sean Olson as well. What follows are some points to be addressed, in general, throughout the document followed by section-by-section comments.

There are inconsistencies between text, schema and examples for certain XML elements appearing throughout the document. That is, they are defined in text, but not in the schema or defined in the examples but not in the text or schema and such. Also, the document needs to be very clear as to what the keys are for XML elements appearing in sequences.
Need to be consistently explicit about which top-level elements are mandatory and which are not (in text, rather than relying on schema definition). It would be useful to also indicate which elements make sense at conference creation time and which at conference run time. For readability, it may be beneficial to indicate, in text, which parts of the document are actually extensible rather than relying on the central text for XML extensibility through namespaces.

No clear indication is given as to how the system/client learns of supported values for specific enumerations or features in a conferencing system (see below 8.)? Surely, a conferencing system may not support all that is defined in this data model, correct?

We also need to work through the details of <available-media> and <media> elements for a user/endpoint in this document as templates also define similar concepts. So the following comments will NOT be going over those elements as these have been brought up elsewhere.

1. Section 3.2 <conference-stage> appears to be in text and examples, but isn't in the schema definition. 

[ON] Correct. In the next version of the draft this information will appear in the schema as well.

It also seems too limiting to just support four values. The implied FSM also is wrong. 

[ON] If you think there are more stages we can define them.

How is this any different than <conference-state>?

[ON] The conference state is from the event package and refers to a running conference.

2. Section 3.2 <web-page> seems redundant, why not just use <service-uris> with defined <purpose>?

[ON] In the "Event Package for Conference State" is already defined like that and this document has to be align with the "Event Package".

3. Section 3.2.2 and Section 3.2.3, There is no need for <conf-uris> and <service-uris> type of <uris-type> to be changed/redefined from what is defined in conference event package. Why not just use the URI schema plus <purpose> element and make it consistent across all the possible URI types?

[ON] Actually, I remember from the last IETF that some people complain exactly about what you are proposing here. That's why I change and I think is much more clear now for a specification prospective like that. The conference event package only defines SIP parameters.

4. Section 3.2.2 <PIN-code> doesn't belong here and it is not defined in [2]. The restriction on a maximum of 6 phone numbers is also arbitrary.
Without some corresponding label or purpose, it will be hard to tell or describe to the user which phone number to use.  Multiple PIN codes should be supported at a minimum. Alternatively, one may remove this element for it to appear elsewhere in description or text. 
Remove any reference to H.320 bonding from the document as it is not necessary and is currently under-specified as to how this will work.

[ON] yes, I will remove the BONDING reference, the <PIN-code> element and the 6 phone number restriction and I will add a new attribute 'purpose' to the <PSTN/ISDN> element.

5. Section 3.2.5 The <codecs> child of <available-media> is too limiting
-- we need to be able to express all the a= attributes in SDP that may accompany a codec if we are to say anything interesting about video codecs.

[ON] This part, as you said in the sentences of your e-mail, is not well-defined and still the authors of the data model are waiting for the new update of the template draft to align this elements. Most of the a=attributes in SDP are not static values and should be defined in the templates. In the other hand, the m=attributes are static data and this information are defined in the data model. 

6. Section 3.5 Please remove <security-mechanism> entirely. It serves no useful purpose from either an organize-time or run-time perspective.

[ON] The <security-mechanism> element contains a series of protocol sub-elements. Each protocol sub-element contains the policy related to the usage of a particular protocol and we think it's important to keep this policies in the data model.

7. Section 3.6 Do floors and floor policies really belong here if floor controls are in templates? 

[ON] Yes, The static information should be defined in the data model.

What is the key? 

[ON] label is the key. Sorry I forget to put this information in the XML schema. In the next version of the draft I will put it.

Does template refer to floors defined here? 

[ON] templates should refer throught the 'label' attribute of the data model to the floors defined there.

8. Section 3.7 What if the conferencing system does not support <join-handling> on a per-user setting, how is it conveyed? 

[ON] <join-handling> is not a mandatory element. If the conferencing system does not support the <join-handling> element, the data model of this conferencing system does not have to define this element.

What if only a subset of joining methods is supported by the system (how would the client know what to choose from the UI)? 

[ON] Then, the data model only would define the methods it supports. It is out of the scope of this draft to define how to do this. This information should be defined in the "conference control protocol" draft.

Would an organizer have to try all possible choices before choosing the one that is supported for a given user? 

[ON] No, the organizer has to define the action if the user does not support this action, the user can not join the conference. 

What about extensibility here? Same applies to other lists and features.

[ON] The extensibility of this list or other lists in the model is defined in Section 5 of the document.

9. Section 3.7 Make <users-must-be-specified> explicitly fall under an admission-policy element. 

[ON] the child element <users-must-be-specified> is closed related with the <dial-in-list> defined in the same element. Still it's important to keep both of them together. 

Also, the schema does not appear to define 
 this element. Rename to something more meaningful: like 'closedAuthenticated' when users must be specified (and authenticated) 
 and 'openAuthenticated' when users can be added after conference activation.
 
     <xs:element name="admission-policy"
 type="tns:admission-policy-type"/>
 
     <xs:simpleType name="admission-policy-type">
         <xs:restriction base="xs:string">
             <xs:enumeration value="closedAuthenticated"/>
             <xs:enumeration value="openAuthenticated"/>
             <xs:enumeration value="anonymous"/>
         </xs:restriction>
     </xs:simpleType>

[ON] I have changed the <users-must-be-specified> element for the one you said here.

10. Section 3.7.1.1 Can we cut <external> for the first version of the model? This can be achieved through simpler operations without complicating the data model itself  

[ON] When XCOn defines this operations that you mention we will cut it from the data model. 

11. Section 3.7.2 What does a domain mean in the <dial-out-list>? (How do you enumerate the entities to dial out to?)  

[ON] Yes, true. I will remove it from the next version.

12. Section 3.7.2 Why differentiate between <dial-out-list> and <refer-list>? It's clear that the Focus will act differently, just don't see the need to explicitly control this difference in behavior. This seems more reasonable to leave up to the implementation. 

[ON] For a matter of clarity. 

13. Section 3.7.2 <dial-out-list>, <dial-in-list> and <refer-list> can be restructured and combined into one list. That is, have a list with all users in it and then enlist allowed joining-method's referencing the available or supported joining-methods in the conferencing system. Make it extensible to support an 'auto' joining method to accomplish previous comment in (12). 

[ON] previous comment in (12)

14. Section 3.7.4 The <privileges-control-list> seems too generic to be implemented in a reasonably interoperable fashion. It also seems to bloat the data model.

[ON] I would be glad to read new ideas about the specification of this element in the data model. I know that this solution is not the best one but, at least, works. 

Also, the conditions are ambiguous in several cases. For example, <participant-passcode> (section 3.7.4.2.1.10) may be meaningless in many conferences. 
How would this condition be interpreted in a conference that has no notion of passcodes?

[ON] If the conference system does not have any notion of passcode, it will not have this rule in its data model.

15. Section 3.7.5 The <authorization-mechanism> element is too limiting ...Digest/Digest-AKA do not even begin to scratch the surface of possibilities. Perhaps more importantly, there is no use-case for this being in the data model at all as it may be derived from other elements like <join-handling> and/or <admission-policy>.

[ON] I have removed this element from the data model. 

16. There are several elements in the document that may require role-based definitions. For example, take <service-uris>. An organizer may want one set of service uri entries for presenters, but a
*different* set of entries for attendees. Similarly, in some cases, one may want to display different display-text based on whether the user is a presenter or the user is an attendee. How would one achieve that? 

[ON] I guess that we could use the <conference-rules> element in the example that you mention.

17. Minor XML schema point: when defining XML elements and their types in schema, it's generally better to use the full name followed by a "-type" to remain consistent. In the schema definition for the data model, this has inconsistently been followed. For example:

         <xs:element name="maximum-user-count"
            type="maximum-user-type" minOccurs="0"/>

 and elsewhere as

           <xs:element name="conference-description"
            type="conference-description-type" minOccurs="1"/>

[ON] thanks, I have fixed that typo.

Srivatsa

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon