Subject: [XCON] data model -03 comments

From: Srivatsa Srinivasan <[email-masked]>
Date: Mon, 20 Nov 2006 19:20:02 -0800

http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-03.txt

Had a chance to look at the updated data model draft, so here are some detailed comments. My prior comments still hold, but I will try not to repeat them here. Overall, simplification would greatly help reduce some of the complexity (see comments below). There are some XML elements that don't appear in the RELAX-NG schema (like 'mute') -- this was discussed and I think a base set of controls should be included in the data model schema and a section that describes how additional controls may be added. That said, this version is certainly better than the previous one!

-- Srivatsa.

Section 3.3.5:
"   The <maximum-streams> contains the maximum number of streams that are
   permitted to be involved in a conference.  It contains a sequence of
   <entry> child elements.  An <entry> element MAY contain the number of
   streams of every specific type of stream, for instance, audio or
   video.  The minimum value permitted is "1" and the maximum value
   permitted is "128".  This element is optional."

[SS] <maximum-user-count> should be sufficient to derive maximum streams as necessary by the conferencing system. What is the intent here (where would this be used)?

Section 3.3.6:

" The <codecs> element
   specifies the allowed codecs in the conference.  It has an attribute
   'decision' that specifies if the focus decides the common codec
   automatically or needs the approvement of the moderator of the
   conference (automatic, moderator-controlled).  The <codecs> element
   contains a <entry> elements.  A <entry> element can have the
   attribute 'name' and 'policy'.  The 'name' attribute identifies a
   codec, and the 'decision' attribute and the policy attribute contains
   the policy for that codec (allowed, or disallowed)."

[SS] What is the real-world scenario that policies and such address with respect to codecs? In the example below, does it imply that a conference client would specify this at conference scheduling time (like an organizer)? Or was this introduced as a result of a non-SIP implementation? In a SIP implementation, would the conferencing client learn of the allowed codecs prior to sending an INVITE to the Focus?
          <codecs decision="automatic">
           <codec name="PCMU" policy="allowed"/>
          </codecs>

"The child elements <mixing-mode>, <mix-level> describe a default
   policy by which the mixer will build the outgoing stream from the
   incoming streams.  Notice that this policy is different that the
   policy describe for the floors for each media.  The <mix-level> child
   element describes the number of participants in audio media streams
   or the number of sub-windows in video media streams (for instance, a
   value of 4 in the <mix-level> element for video stremas means 2x2
   layout).  The <mixing-mode> child element MUST contain one and only
   one of the "Moderator-controlled", "FCFS", and "Automatic" values
   indicating the default algorithm to be use with every media stream."

[SS] This section is not at all clear. Mixing mode is a very specific implementation detail of mixing. What does it mean to define a mixing-mode for every stream -- is this mode applied to the incoming stream to or the outgoing ones from the mixer? And why would a conference participant (organizer or moderator or attendee) be interested in choosing one over the other?

[SS] Also, for layouts, an enumeration of specific layout string identifiers with localized description strings for each layout will be more useful than just an integer aka mix-level. Note that this can be clubbed or rather replaced with a <control> element for layouts. Also, a specific mixer output stream may only support one layout. A client capable of receiving multiple streams may receive more than one stream, each with different layouts or multiple streams each with the same layout. For example, a mixer may output two streams each capable of only a single layout (fixed layouts by the mixer) -- the main video with active speaker and another stream (or multiple streams) of a proprietary mix (like enhanced video from a conference room). This section needs scrubbing.

"3.3.7.1.  mute

   The 'mute' control is used in conjunction with a audio stream to
   cease transmission of associated media.  It has a 'Boolean' value.
   If this control is not specify, the access to the control is not
   available to the client and media SHOULD not be transported for the
   associated media stream."

[SS] This comment applies to all controls. It is quite useful to still have the ability to indicate that the control exists, but cannot be modified. This is useful for example, to know whether another participant is muted or not. This was possible via 'enabled=true' or 'enabled=false' in the previous version of the data model. Why was this removed?

"3.4.  <host-info>

   The <host-info> element contains information about the entity hosting
   the conference.  It contains the <display-text>, <web-page> child
   elements.  These child elements are explained in [2]. <host-info>
   contains the <uris> child element as well. <uris> contains a sequence
   of child elements: <SIP>, <H.323>, and <PSTN/ISDN>.  The child
   elements of <uris> are described in <conf-uris> section."

[SS] Can the <SIP> part be removed in a way that will make this work in a backward-compatible manner? I see some value in leaving H.323 and PSTN/ISDN in there, but the <SIP> can very well be removed. Also "<PSTN/ISDN>" isn't valid XML, you may want to check up on that.

Section 3.5

" The
   <allow-conference-state> element represents a boolean action.  If set
   to TRUE, the focus is instructed to allow the subscription to
   conference state events, such as the SIP Event Package for Conference
   State [2].  If set to FALSE, the subscription to conference state
   events would be rejected.  If this element is undefined it has a
   value of TRUE, causing the subscription to conference state events to
   be accepted."

[SS] The purpose of this element beats me. Is there a scenario where an organizer may want to set this at conference scheduling time? Why restrict only subscriptions? Wouldn't an organizer want to

Section 3.7

"   The <join-handling> element defines the actions used by the
   conference focus to control conference participation.  This element
   defines the action that the focus is to take when processing a
   particular request to join a conference.  This element defines values
   of:
   o  block: This action instructs the focus to deny access to the
      conference.  This action is the default action taken in the
      absence of any other actions.
   o  confirm: This action instructs the focus to place the participant
      on a pending list (e.g., by parking the call on a music-on-hold
      server), awaiting moderator input for further actions.
   o  allow: This action instructs the focus to accept the conference
      join request and grant access to the conference within the
      instructions specified in the transformations of this rule.
   o  IVR: This action instructs the focus that the user has to define
      the PIN code.
   o  directed-operator: This action instructs the focus to direct the
      user to an operator."

[SS] More clarification here would help. For example, what does it mean to have a value of <block> join handling under <users> element (see example below)? Would all join requests be rejected??
         <users>
          <join-handling>block</join-handling>
          <!-- other stuff -->
         </users>

" The <user-admission-policy> element is a list of three elements:
   'closedAuthenticated', 'openAuthenticated', and 'anonymous'.  If the
   <user-admission-policy> element is set to 'closedAuthenticated',
   users must be specified (and authenticate).  If the attribute is set
   to 'openAuthenticated', users can be add after conference activation."

[SS] Please reword: "The <user-admission-policy> is an element that lets an organizer (or a participant with appropriate rights) choose a policy for the conference that controls how users are allowed into the conference. A 'closedAuthenticated' policy requires each conference participant to be in the allowed users list (listed under the <allowed-users-list> XML element) with each participant being sufficiently (up to local policy) authenticated. Conference join requests for users not in the allowed users list or participants not authenticated should be rejected  unless a <join-handling> action of 'confirm' is selected in which case the user is placed on a pending list as indicated earlier. An 'openAuthenticated' policy requires each conferencing participant to be sufficiently authenticated (as before) but does not restrict which participants can join the conference. Typically this implies that anyone capable of authenticating with the conferencing system may join the conference. An 'anonymous' policy allows any join requests in and is the least restrictive in policies."

[SS] Note the combination of <user-admission-policy> and a specific <join-handling> should be worked out. For example, if there is an <allowed-users-list> and <IVR> what does it mean? Why would I need to enter a PIN when I am a) already authenticated b) have joined the conference using a conference URI (example: SIP URI) and c) such that the conferencing system has already authorized me to join the conference?

Section 3.7.1

" The
   'method' attribute is a list with the following values: "dial-in",
   "dial-out, and "refer".  The value "dial-in" is used by the focus to
   determine who can join the conference.  Value "refer" is used by the
   focus to determine the resources that the focus needs to "refer to"
   the conference."

[SS] Why would a conferencing system want to let conference organizer describe "how" a conference participant joins? This is up-to local implementation. If a specific participant has a value of 'dial-in' but is later dialed-out, what does that mean?

"3.7.2.  <privileges-control-list>

   The <privileges-control-list> refers to a virtual set of rights
   pertaining to operations.  This element contains the <conference-
   rules> element.
"

[SS] Re-using common policy is great. But implementing such a system that describes access privileges to XML elements in XML for conferencing is complicated. I suggest that we start simple here and push this section out to a separate draft for further investigation. Since this isn't a must-have scenario moving this section out would greatly simplify this document so energies can be focused on making the simple case work: having a conferencing client inter-op with a conference server for a base set of modalities.

Section 3.8.  <user>

"   The <allow-refer-users-dynamically>, <allow-invite-users-dynamically>
   and <allow-remove-users-dynamically> elements are defined in the
   previous section."

[SS] Would an organizer specify these as conference policies? This ought to be based on the role of the participant instead, right? This again can go into a draft that discusses conference policies. Suggest we leave this out of the base data model.

Section 3.8.1

"   Similarly that the controls defined in the <available-media> element,
   controls that apply to a particular user appear at this place in the
   document.  The <to-mixer> element details properties associated with
   the incoming streams to the mixer. <from-mixer> element details
   properties associated with the outgoing streams from the mixer.  Both
   of these elements have the attribute 'name'.  'Name' attribute has
   the values "VideoIn", "VideoOut", "AudioOut", and "AudioIn".  The
   "VideoOut" and "AudioOut" media streams detail properties associated
   with the outgoing video and audio from the mixer.  The "VideoIn" and
   "AudioIn" media stream details properties associated with the
   incoming video and audio to the mixer.  More values can be defined in
   the future.

   Every of these elements have the <floor> and <controls> child
   elements."

[SS] This needs to be re-worded. A draft I submitted (SDP media usages) has text that can be borrowed to cover this section. If not, let me know and I can help re-word this.

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

---

From: "Oscar Novo \(JO/LMF\)" <[email-masked]>
Date: Tue, 28 Nov 2006 09:51:16 +0100

Hello Srivatsa and Sean,

Thanks for your comments! Comments inline.

-----Original Message-----
From: Srivatsa Srinivasan [mailto:[email-masked]] 
Sent: 21. marraskuuta 2006 5:20
To: [email-masked]
Subject: [XCON] data model -03 comments

http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-03
.txt

Had a chance to look at the updated data model draft, so here are some
detailed comments. My prior comments still hold, but I will try not to
repeat them here. Overall, simplification would greatly help reduce some
of the complexity (see comments below). There are some XML elements that
don't appear in the RELAX-NG schema (like 'mute') -- this was discussed
and I think a base set of controls should be included in the data model
schema and a section that describes how additional controls may be
added. That said, this version is certainly better than the previous
one!

[ON] In version 04, I have introduced the 'mute' element as well as
other elements that were missing. The data model document is getting
very big and sometimes is difficult for me to handle it all. Version 04
has over 80 pages and I guess the document will increase in the
following revisions. Thanks to  point me the missing element.
In IETF-67, I asked to the audience about more controls we should
include in the data model. A 'video-layout' control will be include in
version 04. If you think the data model should include more controls,
please send your suggestions to the mailing list. 

Section 3.3.5:
"   The <maximum-streams> contains the maximum number of streams that
are

[SS] <maximum-user-count> should be sufficient to derive maximum streams
as necessary by the conferencing system. What is the intent here (where
would this be used)?

[ON] This information is defined in the old template draft. A normal
participant in the conference may have different streams (audio, video,
text, whiteboard...). <maximum-user-count> only tells you the maximum
number of participants for every role a conference can hold but not the
maximum number of streams a conference can hold. 
So, <maximum-user-count> is more a 'conference policy' element since
<maximum-streams> is more a 'bandwidth' element.

Section 3.3.6:

" The <codecs> element

[SS] What is the real-world scenario that policies and such address with
respect to codecs? In the example below, does it imply that a conference
client would specify this at conference scheduling time (like an
organizer)? Or was this introduced as a result of a non-SIP
implementation? In a SIP implementation, would the conferencing client
learn of the allowed codecs prior to sending an INVITE to the Focus?
          <codecs decision="automatic">
           <codec name="PCMU" policy="allowed"/>
          </codecs>

[ON] The XCON data model should work beyond SIP protocol. This element
has two scenarios, first the client can learn the allowed codecs and
second the organizer can control which codecs can be use in the
conference.

[SS] This section is not at all clear. Mixing mode is a very specific
implementation detail of mixing. What does it mean to define a
mixing-mode for every stream -- is this mode applied to the incoming
stream to or the outgoing ones from the mixer? 

[ON] It implies to the incoming streams to the server.

And why would a conference participant (organizer or moderator or
attendee) be interested in choosing one over the other?

[ON] I think is quite important to have media control. For instance in a
video conferencing the moderator may want to control the video streams
to show different participants.  

[SS] Also, for layouts, an enumeration of specific layout string
identifiers with localized description strings for each layout will be
more useful than just an integer aka mix-level. Note that this can be
clubbed or rather replaced with a <control> element for layouts. Also, a
specific mixer output stream may only support one layout. A client
capable of receiving multiple streams may receive more than one stream,
each with different layouts or multiple streams each with the same
layout. For example, a mixer may output two streams each capable of only
a single layout (fixed layouts by the mixer) -- the main video with
active speaker and another stream (or multiple streams) of a proprietary
mix (like enhanced video from a conference room). This section needs
scrubbing.

[ON] I think we have discussed this in the last IETF. That's why I will
include a new <video-layout> control in the data model in version 04.

"3.3.7.1.  mute

[SS] This comment applies to all controls. It is quite useful to still
have the ability to indicate that the control exists, but cannot be
modified. This is useful for example, to know whether another
participant is muted or not. This was possible via 'enabled=true' or
'enabled=false' in the previous version of the data model. Why was this
removed?

[ON] It was removed for simplicity. The use case you propose is still
possible, every user has an element floor that tells you if the user is
using that floor or not. The access of a control is specify for the
'read-only' and 'read-write' attributes of the element.

"3.4.  <host-info>

[SS] Can the <SIP> part be removed in a way that will make this work in
a backward-compatible manner? I see some value in leaving H.323 and
PSTN/ISDN in there, but the <SIP> can very well be removed. 

[ON] do you mean backward-compatible with the SIP even package? 04
version is already backward-compatible with the SIP even package.

Also "<PSTN/ISDN>" isn't valid XML, you may want to check up on that.

[ON] Thanks to point me that out. I have corrected it in the 04 version.

Section 3.5

" The

[SS] The purpose of this element beats me. Is there a scenario where an
organizer may want to set this at conference scheduling time? 

[ON] scenario -> low-bandwidth environment.

Section 3.7

[SS] More clarification here would help. 

[ON] Please, provide me with the text and I can include it in the next
version of the draft. I can't see what is unclear. 

For example, what does it mean to have a value of <block> join handling
under <users> element (see example below)? Would all join requests be
rejected??
         <users>
          <join-handling>block</join-handling>
          <!-- other stuff -->
         </users>

[ON] yes

   to 'openAuthenticated', users can be add after conference
activation."

[SS] Please reword: "The <user-admission-policy> is an element that lets
an organizer (or a participant with appropriate rights) choose a policy
for the conference that controls how users are allowed into the
conference. A 'closedAuthenticated' policy requires each conference
participant to be in the allowed users list (listed under the
<allowed-users-list> XML element) with each participant being
sufficiently (up to local policy) authenticated. Conference join
requests for users not in the allowed users list or participants not
authenticated should be rejected  unless a <join-handling> action of
'confirm' is selected in which case the user is placed on a pending list
as indicated earlier. An 'openAuthenticated' policy requires each
conferencing participant to be sufficiently authenticated (as before)
but does not restrict which participants can join the conference.
Typically this implies that anyone capable of authenticating with the
conferencing system may join the conference. An 'anonymous' policy
allows any join requests in and is the least restrictive in policies."

[ON] thanks, your text has been added in the 04 version of the draft.

[SS] Note the combination of <user-admission-policy> and a specific
<join-handling> should be worked out. For example, if there is an
<allowed-users-list> and <IVR> what does it mean? Why would I need to
enter a PIN when I am a) already authenticated b) have joined the
conference using a conference URI (example: SIP URI) and c) such that
the conferencing system has already authorized me to join the
conference?

[ON] The propose of the XCON data model is to provide all the necessary
information in a centralized conference. Providing consistence to the
data model is out-of-scope of the document. The organizer or creator of
the conference should be the person in charge to create consistence in
the data model. 

Section 3.7.1

" The

[SS] Why would a conferencing system want to let conference organizer
describe "how" a conference participant joins? This is up-to local
implementation. If a specific participant has a value of 'dial-in' but
is later dialed-out, what does that mean?

[ON] we have already discussed this in the IETF-66. You were there. :)

[SS] Re-using common policy is great. But implementing such a system
that describes access privileges to XML elements in XML for conferencing
is complicated. I suggest that we start simple here and push this
section out to a separate draft for further investigation. Since this
isn't a must-have scenario moving this section out would greatly
simplify this document so energies can be focused on making the simple
case work: having a conferencing client inter-op with a conference
server for a base set of modalities.

[ON] The data model has to have some kind of common policy. In the
framework draft is specified like that.

Section 3.8.  <user>

"   The <allow-refer-users-dynamically>,
<allow-invite-users-dynamically>
   and <allow-remove-users-dynamically> elements are defined in the
   previous section."

[SS] Would an organizer specify these as conference policies? This ought
to be based on the role of the participant instead, right? This again
can go into a draft that discusses conference policies. Suggest we leave
this out of the base data model.

[ON] same comment than before.

Section 3.8.1

"   Similarly that the controls defined in the <available-media>
element,

[SS] This needs to be re-worded. A draft I submitted (SDP media usages)
has text that can be borrowed to cover this section. If not, let me know
and I can help re-word this.

[ON] Just tell me which text you would like to have and if it's better
than the one in 03 version I can change it.

---

From: Srivatsa Srinivasan <[email-masked]>
Date: Tue, 28 Nov 2006 08:42:29 -0800

More comments inline (preceded by '>'). My suggestion is: if the specific XML
element is not covering a specific use-case in the scenarios document,
remove it. No reason to have various bells and whistles for complicated scenarios
or less-important use-cases. They can very well be extensions.

-- Srivatsa

Section 3.3.5:

>  [SS] Bandwidth?? Please explain. I don't see how declaring the number of
>  streams controls the bandwidth.

Section 3.3.6:

" The <codecs> element

> [SS] The latter is what is bothersome. Why would an organizer want
>      to specify something like this? The codecs should be a negotiation
>      between the Focus+MCU and the conferencing client. Restricting this
>      at conference schedule time makes no sense. IMO this section should
>      be informational only (i.e. read-only) at best or in-fact removed.

> [SS] How would one implement Moderator-controlled, FCFS and Automatic
>      modes? Where are these algorithms defined? I suggest we remove this.

> [SS] I was referring to the mixing-mode. Would the mixing mode be set
>      by an organizer?? Which specific scenario is this covering
>      from the scenarios document?

> [SS] You mean, you will remove mix-level and introduce a video-layout control
>      instead?

"3.3.7.1.  mute

> [SS] These attributes are not defined in the schema. Are you expecting
>      a generic conferencing client to check EVERY element to see if it
>      is read-only or read-write? The conference protocol may very well
>      have a method called modifyEndpointMedia. You are saying here that the
>      client should by looking at every XML element determine whether
>      that operation (with its data) is permissible or not?
>      This makes it MORE complex. It is much simpler to have a schema
>      defined declaring which elements the client should check for read-only
>      or read-write access and that the meaning of those attributes must be
>      defined in text in the data model. Otherwise, this is quite impossible
>      to implement and will cause a whole slew of inter-op issues.

Section 3.5

" The

> [SS] Please explain how this would solve the low-bandwidth problem when you
>      can have a combination of low-bandwidth and high-bandwidth access
>      with different clients. Would the organizer say that all clients would not
>      get notifications? If a client (or the server) deems itself as being on a
>      low-bandwidth network, then it could clearly not SUBSCRIBE (or reject the SUBSCRIBE)
>      Wouldn't that serve the purpose?

Section 3.7

> [SS] Will do later.

> [SS] Huh? I disagree. If the data model is defining elements with
>      certain meaning, shouldn't it be more explicit as to how these
>      elements will be used? Either that or abstract the problem out.

Section 3.7.1

" The

> [SS] Yes and I still do not agree -- I think we should remove 'method'.
>      The only useful scenario in there is perhaps a 'auto-dial-out'
>      attribute or some such indicating that the conference server
>      should automatically dial-out to the user. But that scenario is
>      NOT defined in the scenarios document, so we should remove it :)

> [SS] I am okay with common policy, except for generic logic describing
>      which portions of the XML data structure the client can modify.
>      That is quite hard to implement and will cause inter-op pains. I
>      think having the schema state which elements carry the read-write etc.
>      attributes and the common policy declaring which of those elements
>      can be modified would greatly help.
>      For example, a common policy action of <mute-enabled> is much simpler
>      for an organizer to specify than specifying a pointer to an XML element.
>      In section 3.7.2.2 you have

   o  The <read-write> element represents a boolean action.  If set to
      TRUE, the identity is allowed to modify the element described
      inside the 'element' attribute in the conference policy.  If set
      to FALSE, any modifications to the element are rejected.
   o  The <read-only> element represents a boolean action.  If set to
      TRUE, the identity is allowed to read the element described inside
      the 'element' attribute in the conference policy.  If set to
      FALSE, any attempts to read the element are rejected.

>  [SS] Which 'element' attribute is this referring to?? It does not even
>       appear in the schema!

Section 3.8.  <user>

> [SS] Please remove from the data model. Some of this is SIP specific and
>      also, which specific scenario in the scenarios document is this addressing?