RE: [XCON] Data Model

["Srivatsa Srinivasan" <srivats at microsoft.com>]

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. It also seems too limiting to just
support four values. The implied FSM also is wrong. How is this any
different than <conference-state>?

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

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?

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.

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.

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

7. Section 3.6 Do floors and floor policies really belong here if floor
controls are in templates? What is the key? Does template refer to
floors defined here? Examples show attribute 'label' for <floor> but
schema doesn't.

8. Section 3.7 What if the conferencing system does not support
<join-handling> on a per-user setting, how is it conveyed? What if only
a subset of joining methods is supported by the system (how would the
client know what to choose from the UI)? Would an organizer have to try
all possible choices before choosing the one that is supported for a
given user? What about extensibility here? Same applies to other lists
and features.

9. Section 3.7 Make <users-must-be-specified> explicitly fall under an
admission-policy element. 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:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>					
        </xs:restriction>
    </xs:simpleType>						


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  

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?)  

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. 

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). 

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. 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?

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>.

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? 

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"/>

Srivatsa

> -----Original Message-----
> From: Adam Roach [mailto:adam at nostrum.com]
> Sent: Thursday, May 11, 2006 4:18 PM
> To: XCON-IETF
> Subject: [XCON] Data Model
> 
> [as chair]
> 
> As a reminder, the working group has a milestone for the data model in
> July. In discussions with people to date, it has become extremely
> apparent that people have a lot of opinions on the data model as it
> currently exists.
> 
> I ask everyone participating in the working group to please take the
> time to look over the data model and provide feedback, even if that
> feedback is, "I think the current data model document is complete, and
> I'm happy with it."
> 
> http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-
> 00.txt
> 
> Thanks.
> 
> /a
> 
> _______________________________________________
> XCON mailing list
> XCON at ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon