Re: [XCON] draft-ietf-xcon-common-data-model

Hi Oscar,

Thanks for your reply. I am concerned that some key conferencing data items are missing from the model and instead addressed via extensions.

Specifically I am talking about:-

1. <conference-password.>

This is a one-one mapping with the conference URI. Based on the IETF 68 minutes Re:policies, why is this field still there?

Basically every conference needs at least two passwords - one for particpants & one or more for moderators.

If these fields are going to be provided via some policy schema, then I think that needs to be somehow described so there is a common definition...

[ON] After Chicago's IETF some discussions between SIMPLE and XCON WGs were made to analyzes the gaps between these two WGs. One document was created: 'An Analysis of Feature Parity Between XCON/SIMPLE-Based Chatrooms and Other Chatrooms'. According to that document, the XCON data model This document propose some modificaitons in the XCON data model to fill the gaps between both working groups. One of the elements added was <conference-password>.

Note as well that the <conference-password> accepts more than one occurence. So, the mapping of this element is one-to-many.

2. Demand conferences

On Demand conferences are an industry wide recognised type of conference and therefore should be part of the model.

[ON] I didn't say the model doesn't support demand conferences. The data model does support demand conferences but it's up to the implementor how to implement them. The data model just give the 'tools' and 'elements' to do it. It's out of the scope of the document to explain the diferent scenarios for demand conferences.

3. The pool/lines pool is not specific to PSTN. It is applicable to VOIP also and not the same as <maximun-user-count>.

Basically they are used to divide up conferencing capacity. e.g. scheduled conferences would typically use one pool and

demand another in order to guarantee resources for the scheduled ones...

On the recurring conference, the model doesnt seem to allow modfication of a particular instance in a recurrence pattern.

e.g. I have a weekly recurring conference, on a Friday. However next Friday, the meeting needs to be moved forward by an hour.

How can this be achieved via the model? It would be essential to be able to view/modify individual instances of a conference.

[ON] I'm not an ICal expert but ICal defines different exception operations for recurring conferences. For instance you could use EXDATE or EXRULE operation to limit a recurring conference. As well you can create CHILD and PARENT recurrences to modify the time in a conference. Another option could be to reeschedule your conference. Actually, this is a ICal issue, not a XCON data model issue.

Sean

Sean,

The controls defined in the data model are really basic ones as we agreed in the WG. The controls you suggested in your e-mail can be added to the document in future extensions. Note that the data model is not specific to one protocol (e.g. PSTN, SIP), that's why many times the data model uses general naming in order to fullfil the requirements of all the protocols.

Regarding your comment number 4, the <participant-passcode> and <administrator-passcode> elements were defined in previous versions of the document. However, the WG decided (check the minutes from IETF 68) to leave out the common policy from the data model. The element <conference-password> is used to specify the PIN code of the conference. So, your comment number 5 is fullfil with this element. Concerning your comment number 6, the data model does define a outbound dial list, check the <allowed-users-list> element and its 'method 'attribute.

Answering your general questions briefly:

Number 1: The definition of on-demand conference in the data model it depends pretty much from the implementor. One option it would be not to defined the DTSTART and the DTEND in the <base> element.

Number 2: The pool/lines pool is quiet specific to PSTN. The data model defines the <maximum-user-count> element that it could be used for the same purpose. Extension to this element can be done later.

Number 3: The information for recurring conference can be defined in the <base> element. I suggested you to check RFC 2445. For instance, the example defined in the data model is a recurring conference. Check the example below:

PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN
VERSION:2.0
BEGIN:VEVENT
DTSTAMP:20071003T140728Z
UID:20071003T140728Z-345FDA-carol at example.com
ORGANIZER:MAILTO:carol at example.com
DTSTART:20071017T143000Z
RRULE:FREQ=WEEKLY
DTEND:20071217T163000Z

END:VEVENT
END:VCALENDAR

Cheers,

Oscar

From: xcon-bounces at ietf.org [mailto:xcon-bounces at ietf.org] On Behalf Of Duddy, Sean (Sean)
Sent: 30. kesäkuuta 2008 13:17
To: xcon at ietf.org
Subject: [XCON] draft-ietf-xcon-common-data-model

Hi,

Some comments on the content of this data model re: audio conferencing

(I know these could be accomodated using extensions but maybe they should be part of the standard model as they do seem central to any conferencing solution)

1. Conference recording is missing. Need attribute(s) to indicate if recording is allowed and how it is triggered (automatic or manual)

2. Conference playback is missing. Need attribute to indicate if playback is allowed.

3. Music source selection is missing. Need to be able to set the music source to be played to particpants

waiting to get into the conference.

4. Moderator and conferee passcode. I think the model calls this the <conference-password>, but there needs

to be two, one for moderator and one for conferee. Also as these are DTMF digits, I think the term 'passcode'

is more appropriate than 'password'.

5. Apart from the access control lists, the model seems to be lacking in security, specifically there needs to be a

method to specify PIN codes associated with a conference i.e. user needs to enter this PIN to gain entry to conference

6. Outbound dial list is missing. Need to be able to configure URIs that the moderator/operator can dial out to when conference opens.

Also need to configure how the people on the list get dialled e.g. manually by operator or automatic when moderator joins.

Need to configure what message gets played to them initially also.

7. Entry/Exit tone configuration is missing. Need to be able to specify what should get played when particpants enter/leave

e.g. tone,message,tone&message,none

General questions:

1. How would on-demand conferences be modelled? (Demand conferences are conferences that people can dial into any time i.e. there would be no scheduling information).

2. There is no mention of port/line pools. e.g. scheduled conferences would typically use ports from a reserved pool so one is guaranteed to get into the conference

at conference start time. I think there should be an attribute to specify what pool to use - reserved,unreserved,other.

3. For recurring conferences, where does the original recurrence info get stored? i.e. there is a <conference-time> entry for each recurrence which I assume

will have the start/end timing info for that particular recurrence, but where does the original pattern get stored and how does the model maintain the releationship

between the conferences that make up the pattern? This relationship would be handy to apply a modification to all conferences that make up a recurrence pattern.

Sean

Re: [XCON] draft-ietf-xcon-common-data-model

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.