Subject: [XCON] Re: FW: [Fwd: Re: Elements in the data model]

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 05 Mar 2007 11:30:12 +0100

Oscar Novo (JO/LMF) ha scritto:
> Hi Simon Pietro,
> 
> Here, I send you some comments. Before to put put a new revision of the
> draft I would like to know your opinion for the last comments.
> 
> Regards,
> 
> Oscar
> 

Hi Gonzalo and Oscar,

we're glad you found our comments useful in refining your document. 
We've read the updated draft you sent us, and we think it's a good step 
forward.

We're putting the Mailing List in copy to this message, since we think 
it can be of interest to the ongoing discussion upon the data model.

Regarding your reply to our previous mail, you'll find our new comments 
inline ([S&L&T] as Simon, Lorenzo and Tobia).

>> -------- Original Message --------
>> Subject: Re: Elements in the data model
>> Date: Tue,  6 Feb 2007 12:44:43 +0100
>> From: Simon Pietro Romano <[email-masked]>
>> To: Gonzalo Camarillo <[email-masked]>
>> CC: [email-masked], [email-masked],        Alfonso 
>> <[email-masked]>
>> References: <[email-masked]>
>>
>> Dear Gonzalo,
>>
>> sorry for the late response...as you know we've been working on the
> editing of the DCON drfat proposals during these last days.
>> Please find in the following our considerations about the data model. 
>> Take them
>> as suggestions for improvement and keep in mind that probably many of
> our concerns might disappear with a face-to-face clarification. I'm sure
> the upcoming version of the draft is on the right track and helps
> satisfy most of the "desiderata" expressed by the group. I keep on
> thinking that the data model is the hardest part of the design work for
> any project.
>> We've checked the data model you sent us, analyzing the elements
> marked with an '*' as you suggested, so in the following lines we'll
> provide you with our thoughts and suggestions about them.
>> Comments inline.
>>
>>> !<conference-info>
>>>       |
>>>       |--!<conference-description>
>>>       |     |--<display-text>
>>>       |     |--<subject>
>>>       |     |--<free-text>*
>> We think this can stay.
>>
>>>       |     |--<keywords>
>>>       |     |--<web-page>*
>> This too, even if it would probably fit better in some child element
> of
>> <service-uris>: this way you could have a more detailed list of
> web-pages related to different conference-related services, instead of
> the only one that's reported here.
>> [Gonzalo&Oscar] We have removed this element from this part of the
> data model.
>>>       |     |--<security-level>*
>> This is a little vague and too complex to concentrate in a single
> element. It should probably be elaborated. An idea could be removing it
> for the moment, and leaving it to future extensions where this matter,
> which is a very important and sensitive one, could be deeply considered.
>> [Gonzalo&Oscar] Agree. That's too vague. We have removed this element
> from this part of the data model.
>>>       |     |--<allow-sidebars>*
>> This is fine, even if it would probably fit better in the related
> sidebars section later, but it's just an idea.
>> [Gonzalo&Oscar] we still think this element is fine as a child element
> of the <conference-description> element. The sidebar-by-ref and
> sidebar-by-val sections are not inside any global sidebar element just
> for backward compatibility with RFC 4575.

[S&L&T] That's okay then.

>>>       |     |--<conference-stage>*
>> Is this a typo for <conference-state> or is it <conference-stage>? It
> should be described better, but it probably is fine to let it stay.
>> [Gonzalo&Oscar] It wasn't a typo but we've decided to remove it
> because it wasn't clear the propose of this element. 
>>>       |     |--<conference-time>*
>>>       |     |      |--<entry>*
>>>       |     |      |    |--<base>*
>>>       |     |      |    |--<mixing-start-offset>*
>>>       |     |      |    |--<mixing-end-offset>*
>>>       |     |      |    |--<can-join-after-offset>*
>>>       |     |      |    |--<must-join-before-offset>*
>>>       |     |      |    |--<request-user>*
>>>       |     |      |    |--<notify-end-of-conference>*
>>>       |     |      |    |--<allowed-extend-mixing-end-offset>*
>> We think that this one, as the security-related element before, should
> be better elaborated and analyzed. You could leave the <base> as a stub,
> and furtherly enhance and improve it in later extensions.
>> [Gonzalo&Oscar] we have read this section again and we can't see what
> is not clear, we need a bit more help from you. what exactly you don't
> understand from the text? Which element is not clear enough? Maybe, do
> you have in mind a better text to put in the draft?

[S&L&T] <base> is surely enough to handle scheduled conferences and 
their optional recurrency, being it an iCal object. As to the rest, 
<can-join-after-offset>, <must-join-after-offset> and 
<notify-end-of-conference> are useful entries, but we don't see the 
point of having the others in this data model, if it really means to be 
only a base for future extensions.

>>>       |     |           ...
>>>       |     |--<conf-uris>
>>>       |     |      |--<SIP>*
>>>       |     |      |    |--<uri>
>>>       |     |      |    |--<display-text>
>>>       |     |      |    |--<purpose>
>>>       |     |      |--<H323>*
>>>       |     |      |    |--<H.323-alias>*
>>>       |     |      |    |--<H.323-URI>*
>>>       |     |      |--<PSTN-ISDN>*
>>>       |     |      |    |--<phone number>*
>>>       |     |      |    |--<PIN-code>*
>>>       |     |      |    |--<purpose>*
>>>       |     |      |    |--<rate>*
>>>       |     |      ...
>> The ones that are reported are fine but there only are CSP (Call
> Signaling Protocol) URIs. Will other media URIs be put here as well?
>> We're thinking about IM-related resources, as Jabber channels that
> could be associated with the conference for text, or any other URI
> related to any media that could be available in the conference (e.g.
>> whiteboarding). This is more a question than a suggestion, of course,
> and it can be left to future study and extensions.
>> [Gonzalo&Oscar] yes, other media URIs should be put in this section
> (such Jabber), not only CSP.
>>
>>>       |     |--<service-uris>
>>>       |     |      |--<SIP>*
>>>       |     |      |    |--<uri>
>>>       |     |      |    |--<display-text>
>>>       |     |      |    |--<purpose>
>>>       |     |      |--<H323>*
>>>       |     |      |    |--<H.323-alias>*
>>>       |     |      |    |--<H.323-URI>*
>>>       |     |      |--<PSTN-ISDN>*
>>>       |     |      |    |--<phone number>*
>>>       |     |      |--<BFCP>*
>>>       |     |      |    |--<conference-ID>*
>>>       |     |      ...
>> The BFCP ConferenceID should be removed from here and put in
> <floor-information> instead, where it would probaby fit much better. And
> as we suggested before, maybe also web-related URLs as the conference
>> web-page(s) would stay better here than where they are now.
>>
>> [Gonzalo&Oscar] we have moved the conferenceID to the
> <floor-information> element.
>>>       |     |--<maximum-user-count>
>>>       |     |      |--<entry>*
>>>       |     |      |--<entry>*
>>>       |     |      ...
>> This is fine where it is but the <entry> child is not described well
> enough. What will it contain? Will it have subchilds, and if so, which
> ones?
>> [Gonzalo&Oscar] we have removed the <entry> child element from the
> <maximum-user-count> element to have it align with RFC 4575. 
>>>       |     |--<maximum-streams>*
>>>       |     |      |--<entry>*
>>>       |     |      |--<entry>*
>>>       |     |      ...
>> This is too mixing-related in our opinion, and so it would probably be
> better removing it for now and leaving it to future extensions. This
> would allow better coordination with the work currently carried out by
> the MediaCtrl WG, which could give us all a clearer view on what is
> needed by the AS about mixing.
>> [Gonzalo&Oscar] we have removed the <maximum-streams> element from the
> data model.
>>>       |     |--!<available-media>
>>>       |     |      |--!<entry>
>>>       |     |      |     |--<type>
>>>       |     |      |     |--<display-text>
>>>       |     |      |     |--<status>
>>>       |     |      |     |--<mixing-mode>*
>>>       |     |      |     |--<mix-level>*
>>>       |     |      |     |--<codecs>*
>>>       |     |      |     |    |--<entry>*
>>>       |     |      |     |    |--<entry>*
>>>       |     |      |     |    ...
>>>       |     |      |     |--<controls>*
>>>       |     |      |     |    |--<mute>*
>>>       |     |      |     |    |--<gain>*
>>>       |     |      |     |   ...
>> Same as before, the mixing-related matter is a little too vague at the
> moment.
>> [Gonzalo&Oscar] Exactly which element is too vague at the moment?
> <mixing-mode>? <mix-level>? We can remove them if they are not enough
> clear.

[S&L&T] Having basic controls for media is absolutely fine, but only as 
long as they keep being an abstraction to be laterly bound to the 
underlying mixing layer, whatever and however this is made. 
<mixing-mode> and <mix-level> are a bit too mixing-oriented to meet this 
requirement, while <codecs> should be kept at best as informative only, 
read-only entries, and left to the CSP negotiation while joining a 
conference. Some similar issues were raised by Srivatsa Srinivasan too 
in a mail on the ML a couple of months ago.

>>>       |     |      |--<entry>
>>>       |     |      |     |--<type>
>>>       |     |      |     |--<display-text>
>>>       |     |      |     |--<status>
>>>       |     |      |     |--<mixing-mode>*
>>>       |     |      |     |--<mix-level>*
>>>       |     |      |     |--<codecs>*
>>>       |     |      |     |    |--<entry>*
>>>       |     |      |     |    |--<entry>*
>>>       |     |      |     |    ...
>>>       |     |      |     |--<controls>*
>>>       |     |      |     |    |--<pause-video>*
>>>       |     |      |     |    |--<video-layout>*
>>>       |     |      |     |   ...
>> Idem.
>>
>>>       |     |      ...
>>>       |
>>>       |--<host-info>
>>>       |     |--<display-text>
>>>       |     |--<web-page>
>>>       |     |--!<uris>
>>>       |     |     |--!<SIP>*
>>>       |     |     |    |--!<uri>*
>>>       |     |     |    |--<display-text>*
>>>       |     |     |    |--<purpose>*
>>>       |     |     |--<H323>*
>>>       |     |     |    |--<H.323-alias>*
>>>       |     |     |    |--<H.323-URI>*
>>>       |     |     |--<PSTN-ISDN>*
>>>       |     |     |    |--<phone number>*
>>>       |           ...
>> What difference is there between these URIs and the ones that have
> been reported before? Anyway, the observations are the same as the ones
> we made for the URIs before.
>> [Gonzalo&Oscar] This element contains information about the entity
> hosting the conference. <conf-uris> contains the URI to be used in order
> to access the conference.
>>
>>>       |--<conference-state>
>>>       |     |--<allow-conference-state>*
>> We read on the draft that this element is related to the possibility
> to subscribe to the conference event package. If so, it is probably fine
> where it is, but a clearer name (e.g.
>> <allow-conference-event-subscription>) wouldn't hurt, since the
> current name can be confusing.
>> [Gonzalo&Oscar] yes, the name you suggest is much more clear. Good
> point. We have change it. 
>>>       |     |--<user-count>
>>>       |     |--!<active>
>>>       |     |--<locked>
>>>       |
>>>       |--<floor-information>*
>>>       |     |--<allow-floor-events>*
>>>       |     |--<floor-request-handling>*
>>>       |     |--<conference-floor-policy>*
>>>       |     |     |--<floor>*
>>>       |     |     |    |--<media-types>*
>>>       |     |     |    |--<algorithm>*
>>>       |     |     |    |--<max-floor-users>*
>>>       |     |     |    |--<moderator-uri>*
>>>       |     |     |    |--<moderator-uri>*
>>>       |     |     |   ...
>>>       |     |     ...
>> As we suggested befre, the BFCP ConferenceID that crrently sits in the
> service URIs should be moved somewhere in here, where it surely is its
> place. 
>> [Gonzalo&Oscar] yes, now it's where you suggested 
>>
>> Regarding the existing elements, what exactly is the <moderator-uri>?
> Is it a CSP-related URI or a BFCP UserID? 
>> [Gonzalo&Oscar] BFCP UserID
>>
>> It would probably be better having it be the second, rather than the
> first, and thus having its name be something like <chair-id> or the
> like. The rest is fine, other policies can be added in future
> extensions.
>> [Gonzalo&Oscar] we have change the name of moderator-uri to chair-id.
>>
>>>       |
>>>       |--!<users>
>>>       |     |--<join-handling>*
>>>       |     |--<user-admission-policy>*
>>>       |     |--<allowed-users-list>*
>>>       |     |     |--<target>*
>>>       |     |     |-- ...
>> <join-handling> and <user-admission-policy> are somewhat confusing and
> overlapping concepts: it could be a good idea finding a way to merge
> them together, unless they explicitely refer to different and separate
> matters.

[S&L&T] About this, their difference is clearer now. However, 
<join-handling> envisages the possibility of having a PIN-driven access 
to the conference by means of IVR interaction. But where is this PIN 
stored in the data model, if needed?

>>
>>>       |     |
>>>       |     |--<privileges-control-list>*
>>>       |     |    |--<conference-rules>*
>>>       |     |    |     |--<entry>*
>>>       |     |    |     |     |--<condition>*
>>>       |     |    |     |     |     |--<identity>*
>>>       |     |    |     |     |     |     |
>>>       |     |    |     |     |     |     ...
>>>       |     |    |     |     |     |
>>>       |     |    |     |     |     |--<validity>*
>>>       |     |    |     |     |     |     |--<from>*
>>>       |     |    |     |     |     |     |--<until>*
>>>       |     |    |     |     |
>>>       |     |    |     |     |--<actions>*
>>>       |     |    |     |     |     |
>>>       |     |    |     |     |     ...
>>>       |     |    |    ...
>> Since you just proposed the new discussion about policies on the WG
> Mailing List, it may be better waiting for what will come out from the
> discussion before putting policy-related stuff in the data model that
> could be latterly rejected, thus leaving the matter to future
> extensions.
>> [Gonzalo&Oscar] we have removed the <privileges-control-list> from the
> new version of the draft.
>>>       |     |
>>>       |     |--!<user>
>>>       |     |    |--<display-text>
>>>       |     |    |--<associated-aors>
>>>       |     |    |--<provide-anonymity>*
>> This <provide-anonimity> is a little confuse, it should be better
> explained and elaborated, otherwise it would be better to remove it for
> the moment.
>> [Gonzalo&Oscar] we have try to explain a bit better this element.
> Please, tell us if now it's a bit more clear.

[S&L&T] It is a bit clearer now, though it still presents some 
ambiguity. The draft states: "the focus provides to the rest of the 
participants an anonymous identity for that user, for example 
anonymousX". What is not clear is: does this 'masquerading' also affects 
the way the user information is stored in the data model as a whole, or 
only its appearance to other users requesting or being notified about 
it? To be more precise, is the real information about the user stored in 
the data model, and then faked when this information needs to be shown 
to the outside, or is the user completely anonymized directly in the 
data model itself?

>>>       |     |    |--<roles>
>>>       |     |    |    |
>>>       |     |    |   ...
>>>       |     |    |--<languages>
>>>       |     |    |--<cascaded-focus>
>>>       |     |    |--<sphere>*
>> Why calling this <sphere> instead of <state>?
>>
>> [Gonzalo&Oscar] We have remove sphere from the data model. It was too
> vague.
>>>       |     |    |--<allow-refer-users-dynamically>*
>>>       |     |    |--<allow-invite-users-dynamically>*
>>>       |     |    |--<allow-remove-users-dynamically>*
>>>       |     |    |--!<endpoint>
>>>       |     |    |      |--<display-text>
>>>       |     |    |      |--<referred>
>>>       |     |    |      |--<status>
>>>       |     |    |      |--<joining-method>
>>>       |     |    |      |--<joining-info>
>>>       |     |    |      |--<disconnection-method>
>>>       |     |    |      |--<disconnection-info>
>>>       |     |    |      |--!<media>
>>>       |     |    |      |    |--<type>
>>>       |     |    |      |    |--<display-text>
>>>       |     |    |      |    |--<label>
>>>       |     |    |      |    |--<src-id>
>>>       |     |    |      |    |--<status>
>>>       |     |    |      |    |--<to-mixer>*
>>>       |     |    |      |    |      |--<floor>*
>> This <floor> is probably out of place here, since all the
> floor-related information has its own element that takes care of all
> media associations as well, and consistency and alignment problems could
> arise.
>> [Gonzalo&Oscar] the floor-information element gives general
> information about the floors in the conference. This <floor> element
> just said if a user has a floor or not in a media stream. So, it's
> related to every user.

[S&L&T] As long as it is read-only, then it's fine. Otherwise, it could 
give more than a problem in real scenarios.

>>>       |     |    |      |    |      |--<controls>*
>>>       |     |    |      |    |      |      |--<mute>*
>>>       |     |    |      |    |      |      |--<gain>*
>>>       |     |    |      |    |      |     ...
>>>       |     |    |      |    |--<from-mixer>*
>>>       |     |    |      |    |      |--<floor>*
>> Same as before.
>>
>>>       |     |    |      |    |      |--<controls>*
>>>       |     |    |      |    |      |      |--<pause-video>*
>>>       |     |    |      |    |      |     ...
>> See above about mixing.
>>
>> [Gonzalo&Oscar] we have discuss already in the XCON WG that we provide
> some basic controls in the data model (audio and video), even though
> that the information is a bit vague.

[S&L&T] As we stated before, having basic controls for media is 
absolutely fine, but only as long as they keep being an abstraction to 
be laterly bound to the underlying mixing layer, whatever and however 
this is made. In this case, the controls you've put in the data model 
are probably fine.

>>>       |     |    |      |   ...
>>>       |     |    |      |--<call-info>
>>>       |     |    |      |    |--<sip>*
>>>       |     |    |      |    |   |--<display-text>
>>>       |     |    |      |    |   |--<call-id>
>>>       |     |    |      |    |   |--<from-tag>
>>>       |     |    |      |    |   |--<to-tag>
>> What is this <sip> element here? It should be better described, we
> sincerely don't know what it is and if it should stay or not.
>> [Gonzalo&Oscar] sorry, we haven't modify anything about this element,
> we have removed the * from the new version. This element is described in
> RFC 4575. That's why here we don't describe it again.

[S&L&T] Then it could probably be a good idea extending it to other CSPs 
too, by adding new entries to cover H.323, PSTN and the like. Or, even 
better, add a generic element that has the protocol as attribute, to 
make it easily extendible for new protocol entries; this suggestion 
applies to other sections where different protocols appear as well.

>>>       |          ...    ...
>>>       |--<sidebars-by-ref>
>>>       |     |--<entry>
>>>       |     |     |-- <user>
>>>       |     |     |-- <display-text>
>>>       |     |--<entry>
>>>       |     |     |-- <user>
>>>       |     |     |-- <display-text>
>>>       |     ...
>>>       |--<sidebars-by-val>
>>>       |     |--<entry>
>>>       |     |     |
>>>       |     |    ...
>>>       |     |--<entry>
>>>       |     |     |
>>>       |     ...   ...
>> That's all! If you have any doubt or question regarding any of our
> points, feel absolutely free to ask.
>> We're looking forward to receiving your comments, and we hope a new
> version of the data model will come out soon.
>> Cheers,
>>
>> Simon, Lorenzo and Tobia

To conclude, we found some small typos and possible errors while reading 
the draft:

3.2.1:
A "could used" and "withing" can be found in the text.

3.2.1.1:
The chair is presented as a role which can grant a floor, which is 
incorrect. A chair can only accept requests, which are however then 
subject to the FCS queues and policies before they can be granted. About 
this, we take advantage of this point to raise a possible problem in the 
BFCP draft: should it be possible for the chair to reorder a queue in 
the FCS by means of a new ChairAction with an ACCEPTED state in it? a 
ChairAction that would update a previous ACCEPTED one. Think for example 
about a chair wanting a participant, who is currently fourth in queue, 
to actually be the next person to be granted a floor: a new ChairAction 
imposing a 1st position in queue would have this result. However, such a 
feature is not envisaged in the BFCP draft, so it is not clear wheter it 
should be actually possible or not, since it would invasively override 
the local FCS queue policies and algorithms.

3.2.1.2:
This section states that "the user can join a new floor in a different 
role." Is this a typo for "join a new conference"?

4.1.3:
The <service-uris> description still has the <BFCP> element in it, while 
it has been removed.

That's all, we hope this second round of comments will help you 
completing the refining of the document.
We're looking forward to receiving new comments, both from you and from 
the WG, in case doubts or concerns about any of our points should come out.

Cheers,

Simon, Lorenzo and Tobia

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Università degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]

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