All,
Here are our consolidated comments while wearing our
"Avaya" hats.
pg13, Figure 3 & pg 14, S4.2
*
Where do generic / proprietary conference attributes fit in e.g.
pin-list, recording, billing, call flow type , biometric , data, video ,
annunicator msgs?
[ON] The data model is extensible. Proprietary elements can be
added in future extensions. Check section 6 of the
draft.
pg14, S4.2.1
* this assumes only a specific
language is available, what about country variants and fallback e.g. en,
en_gb
[ON] The language datatype
accepts strings that are conforming with RFC3066bis and RFC4646 and these drafts
accepts country variants and many other possibilities. I recommend you to check
these RFC.
pg 15, S4.2.6
* Does this imply a default of
false if not specified ?
[ON] This is up to local
policy.
What about size of sidebars, number of
sidebars
[ON] We decided to leave this information
out of the data model. Always is possible to add it in some
extensions.
pg 15, S4.2.7
* Does their need to be
anything about demand / scheduled / adhoc (tui)
[ON] Possible to add it in some extensions if you need
it.
* Mandate all date times in
UTC. It's up to a client application to convert to / from local time as
appropriate. How to handle timezones and variation in dst rules or is this a
problem for the OS and main userspace runtime library?
[ON] The data model only
defines the information in a conference. How to handle this information is up to
every implementor.
* Should there be a way of
linking via a uri to the ical object the base element under
conference-time\entry.
* I'm not familiar enough with
ical rfc, but can it specify perpetual conferences, recurring series with odd
exceptions ? Tz / dst changes that are outside normal rules due to political
changes.
[ON] I recommend you to check RFC
2445.
* required-participant
attribute under mixing-start-offset has no apparent definitions of the various
roles
[ON] The definitions of the
roles is out of scope of this document.
* can-join-after-offset
doesn't mention DTSTART and signed integer
[ON] It's similar
to <must-join-before-offset> but I'll add it to make it clear.
*
allowed-extend-mixing-end-offset has no apparent limits on size, duration
, number of extension periods
[ON] it's open to future
extensions
* Would there be a requirement
for accessing current time and tz on server. How would one handle a distributed
/ dispersed server deployment?
[ON] this is out of scope of this document.
* In the Schema, the *-offset elements
are dates, while in this section they are described as integer offsets
[ON]
I'll fix that in the text.
pg 16, S4.2.8
*
Must be able to repesent multiple
access numbers to same logical conference e.g. international, toll free, local
access for PSTN users. Howto represent a conference which spans multiple
dispersed bridges
[ON] We already discussed that in IETF-69 and the WG
consensus was to have one element type.
* There is only one
<conference-password> element. We have at least two levels of
password and can have multiple passwords for the same level. How would this be
represented?
[ON] I'll extend the schema to accept this
case.
pg17, S4.2.10
* would S4.2.10 depend on S4.2.11, and
is there a way to capture that dependency
[ON] up to the
implementor.
* Does this maximum user count refer to the
maximum users supported by the media mixing servers, or the limit for the
conference?
[ON] The maximum users allowed
to join the conference.
* Is there any way to indicate that
the maximum-user-count can be increased on demand if necessary?
[ON]
not now but you could extend it
later.
pg 18, S4.2.11
* No mention of data,
whileboarding. Need a way to indicate bandwidth, preferred audio / image
formats.
[ON] the data model only defined
basic media: audio and video.
* What type of <mute> does
<mute> provide. We differentiate two types of mute: "mute" is a mute
that can be applied by a moderator or by yourself. It can only be removed
by yourself. "silence" is a mute that can only be applied or removed by a
moderator.
[ON] this element only
describes the cease of audio but it does not differentiate who has the right to
applied or remove it.
* How can other controls be
exposed?
pg19, S4.3
* Failover scenario - tcp-ip possibly changes
[ON] I don't understand what's the
problem here
pg 19, S4.4
*
Is this data model only concerned with runtime info? If not need a way to
indicate cancelled, billed, aborted, confirmed and possibly other states
[ON] check the <locked> and
<active> elements, section 4.4.3 and
4.4.4
pg 22, S4.6
*
Presumably user can have multiple roles simultaneously.
[ON] are you talking about 4.6.5.4
section? Section 4.6 doesn't defined any role.
pg23, S4.6.3
* No definition of roles, format of uris
[ON] i'll add them in the
text.
pg 24, S4.6.4
*
No definition of roles,
format of uris
[ON]
idem
pg 24, S4.5.0
* How are user PINs represented, i.e.
the number unique to each user that allows them to identify themselves via the
TUI after entering the conference password
[ON] up to the implementor.
pg 27, S4.6.5.10
* Can multiple users hold the floor
in the same floor at the same time? Can a user hold multiple floors at the same time? An
example of these would be good.
[ON] check RFC4582 for this
questions.
pg28, S4.6.5.10
*
Data, whiteboarding in the from mixer element
[ON] the data model only defined basic media: audio and
video.
pg28, S5
* This section duplicates
Appendix A., shouldn't the schema be
defined in one location only in order to reduce
the posibility of synchronization errors
[ON]
One schema is generated using the other. That's a WG consensus to make it more
understandable for the reader. The possibility of synchronization errors are
minimal.
