Subject: [XCON] Follow-up on the XCON data model draft

From: Miguel Garcia <[email-masked]>
Date: Fri, 09 Nov 2007 12:27:21 +0200

Hi:

This is the first part of a follow-up of the comments on the XCON data 
model that I posted earlier. I haven't done the full follow-up, but I 
think there is enough meat for discussion. I will try to complete the 
follow-up sometime next week.

My original comments are:

http://www1.ietf.org/mail-archive/web/xcon/current/msg02025.html

And I have been looking at their implementation in vesion -06 of the
data model:

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

Let me highlight here issues that require a bit more of discussion. New
comments are preceded by "[MG]":

----
6) Figure 1. There are one or more objects called "Conference Object".
Each one contains just another object called "Conference Information
Data Model". According to the figure, the Conference Object just
contains a Conference Information Data model, nothing else, nothing
more. This makes me think that both things are the same. Or, in other
words, perhaps the "Conference information data model" should be removed
from the figure. Or, if it shouldn't, then you need to describe the
relation between both in textual form.

[MG] I haven't seen any action in the figure nor in the text.

-----

8) I miss a motivation for the existence of roles at the beginning of
Section 3.2

[MG] I noticed that the discussion about the actual values of roles have
been dropped. I don't have any problem about that (although I prefer to
have roles). However, there are some leftovers.

- Section 4.2.6:

       The <mixing-start-
       offset> has the mandatory 'required-participant' attribute.  This
       attribute has one of 4 values: "none", "administrator",
       "moderator", and "participant".  This attribute allows a
       privileged user to define when media mixing starts based on the
       latter of the mixing start time, and the time the first
       participant, administrator, or moderator arrives.

So, I guess the 'required-participant' attribute is referring to roles,
and has 4 roles values... however the document does not define the
roles... so I see a contradiction here.

The same applies to the <mixing-end-offset>, <can-join-after-offset>,
and <must-join-before-offset> elements.

I think the draft is now lame, assuming certain roles but not clearly
indicating them.

--------

11) Section 4, the paragraph above Figure 2: it mentions the XCON-URI
without a reference to where it is defined. Then I saw it in the IANA
considerations section, so THIS might be the canonical document that
defines it. So, I think the XCON URI deserves a section by itself,
describing the semantics, syntax, etc.

[MG] While the section to the XCON URI has been devoted, I don't like
the fact that you write the syntax embedded in the IANA considerations
section. Such section is not the place for that. The current Section 3.3
needs to add a subsection where write the syntax of the URI.

---------

15) Section 4.1.1, second paragraph. The <mixing-start-offset> element
is mixing two semantics: one one side, it indicates whether mixing
starts according to either a specified time or when a participant with a
role joins. I think it would much clear to create three elements
instead: one is a <mixing-start>, which can take the values "by-time",
"by-joining-role", or "at-first-join". Another would be the existing
<mixing-start-offset>, which would be restricted to indicating a time,
and only available when <mixing-start> takes the value "by-time". A
third one is <mixing-start-role> which would take the values
"participant", "moderator", "administrator", and is only available is
<mixing-start> takes the value "by-joining-role".

[MG] What happened to this comment?

----

19) Section 4.1.5.1.1 defines the <mute> element and Section 4.1.5.1.2 
defines the <pause-video> element. I think these two are very similar, 
the only difference being that the former applies to audio streams, the 
latter to video streams. I would like to see a single element, perhaps 
called <output-stream-enabled> or something like that. This could apply 
for any kind of media stream, even for MSRP.

[MG] What happened to this comment? I think we shouldn't be defining 
specif actions on a per media stream basis. What we need here is an 
element to disable a media stream, no matter whether the stream is of 
type, audio, video, gaming, text, message, or something else.

------

20) Section 4.1.5.1.3 defines the <gain> element. I am missing 
attributes that defines the minimum and maximum levels. Without it, if I 
get that the mixing level is 10, I have now idea if it is 10 in a scale 
1-10, 10 in a scale 1-100, or 10 in a scale 1-1000. Further more, 
without the maximum/minimum level, it wouldn't be possible to create a 
UI scale representation, making the control totally useless.

[MG] While the text now speaks about two attributes, 'min' and 'max', 
the do not appear in the RelaxNG nor in the XML schema.

On the other hand, checking the RelaxNG schema, I have now realized that 
there is a minInclusive and maxInclusive values, effectively putting 
limits to the scale in the XML schema. I would like to ask opinions for 
what is the desired option here. There are 3 of these options.

a) <gain> with limits (minInclusive, maxInclusive). So, this effectively 
hard codes the limits of the <gain> scale in the schema. The minimum and 
maximum values are <gain>-127</gain> and <gain>127</gain>.

b) <gain> with the 'min' and 'max' attributes. So, in this way, the user 
controls the range of the scale. I could therefore say <gain min=0 
max=10>7</gain>. The server would need to re-scale to whatever scale the 
server implements.

c) <gain> with limits (minInclusive, maxInclusive) and 'min' and 'max' 
attributes. I think this is the worst solution, because it has the 
constraints of both solutions.

So, I think I am going to propose solution a), which is essentially 
equivalent to withdrawing my initial comment. But I would suggest that 
you mention the hardcoded limits in the text, to avoid mislead the 
reader. My prposal for the description of the <gain> element in Section 
4.2.10 is:

       *  The <gain> element is used in conjunction with a media output
          stream to indicate the amount of amplification of an audio
          stream. The value is an integer number that ranges from -127 to
          127. If this control is not specified,
          access to the control is not available to the client.

----

End of first part.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

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