From xcon-bounces@ietf.org Wed Jul 2 04:25:07 2008 Return-Path: X-Original-To: xcon-archive@megatron.ietf.org Delivered-To: ietfarch-xcon-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AFC03A698D; Wed, 2 Jul 2008 04:25:07 -0700 (PDT) X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E683A698D for ; Wed, 2 Jul 2008 04:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.648 X-Spam-Level: X-Spam-Status: No, score=-5.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfhcweLBtiS7 for ; Wed, 2 Jul 2008 04:25:04 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1B5043A6982 for ; Wed, 2 Jul 2008 04:25:04 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 97E1721262; Wed, 2 Jul 2008 13:25:12 +0200 (CEST) X-AuditID: c1b4fb3c-ae09bbb00000193b-16-486b65989be6 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5E101205F5; Wed, 2 Jul 2008 13:25:12 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Jul 2008 13:25:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Jul 2008 13:25:50 +0200 Message-ID: In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F717EE5B8@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] draft-ietf-xcon-common-data-model Thread-Index: Acjamnjp9/SPqcBJRvCsEMWbxTmDMwBjZbrw References: <4408C6EC74CC3D42824FD68FDA8E8F717EE5B8@306900ANEX2.global.avaya.com> From: "Oscar Novo" To: "Duddy, Sean (Sean)" , X-OriginalArrivalTime: 02 Jul 2008 11:25:51.0792 (UTC) FILETIME=[62702300:01C8DC36] X-Brightmail-Tracker: AAAAAA== Subject: Re: [XCON] draft-ietf-xcon-common-data-model X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1282755370==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1282755370== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8DC36.622FCB06" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8DC36.622FCB06 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sean, =20 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.=20 =20 Regarding your comment number 4, the and = 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 = 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 element and its 'method 'attribute.=20 =20 Answering your general questions briefly: =20 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 element.=20 Number 2: The pool/lines pool is quiet specific to PSTN. The data model = defines the element that it could be used for the = same purpose. Extension to this element can be done later.=20 Number 3: The information for recurring conference can be defined in the = 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@example.com ORGANIZER:MAILTO:carol@example.com DTSTART:20071017T143000Z RRULE:FREQ=3DWEEKLY DTEND:20071217T163000Z END:VEVENT END:VCALENDAR =20 Cheers, =20 Oscar ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Duddy, Sean (Sean) Sent: 30. kes=E4kuuta 2008 13:17 To: xcon@ietf.org Subject: [XCON] draft-ietf-xcon-common-data-model Hi, Some comments on the content of this data model re: audio = conferencing=20 (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) =20 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 = , but there needs=20 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=20 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=20 e.g. tone,message,tone&message,none=20 =20 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 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. =20 Sean ------_=_NextPart_001_01C8DC36.622FCB06 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sean,
 
The=20 controls defined in the data model are really basic ones as we agreed in = the WG.=20 The controls you suggested in your e-mail can be added to the document = in future=20 extensions. Note that the data model is not specific to one protocol = (e.g. PSTN,=20 SIP), that's why many times the data model uses general naming in order = to=20 fullfil the requirements of all the protocols.
 
Regarding your comment number 4, the = <participant-passcode> and=20 <administrator-passcode> elements were defined in previous = versions of the=20 document. However, the WG decided (check the minutes from IETF 68) to = leave out=20 the common policy from the data model. The element=20 <conference-password> is used to specify the PIN code of the = conference.=20 So, your comment number 5 is fullfil with this element. Concerning your = comment=20 number 6, the data model does define a outbound dial list, check the=20 <allowed-users-list> element and its 'method=20 'attribute. 
 
Answering your general questions briefly:
 
Number=20 1: The definition of on-demand conference in the data model it depends = pretty=20 much from the implementor. One option it would be not to defined the = DTSTART and=20 the DTEND in the <base> element.
Number=20 2: The pool/lines pool is quiet specific to PSTN. The data model defines = the=20 <maximum-user-count> element that it could be used for the same = purpose.=20 Extension to this element can be done later.
Number=20 3: The information for recurring conference can be defined in the = <base>=20 element. I suggested you to check RFC 2445. For instance, the example = defined in=20 the data model is a recurring conference. Check the example=20 below:

 PRODID:-//LlamaSpinner Inc.//NONSGML=20 CamelCall//EN
 VERSION:2.0
 BEGIN:VEVENT
 DTSTAMP= :20071003T140728Z
 UID:20071003T140728Z-345FDA-carol@example.com<= BR> ORGANIZER:MAILTO:carol@example.com
 DTSTART:20071017T143= 000Z
 RRULE:FREQ=3DWEEKLY
 DTEND:20071217T163000Z<= /DIV>
 END:VEVENT
 END:VCALENDAR
<= /SPAN>
 
Cheers,
 
Oscar

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

Hi,
    Some comments on the = content of this=20 data model re: audio conferencing
(I know these could be accomodated using=20 extensions but maybe = they should be=20 part of the standard model as they do seem central to any conferencing=20 solution)
 
1. = Conference=20 recording is missing. Need attribute(s) to indicate if recording is = allowed and=20 how it is triggered (automatic or manual)
2. = Conference=20 playback is missing. Need attribute to indicate if playback is=20 allowed.
3. = Music source=20 selection is missing. Need to be able to set the music source to be = played to=20 particpants
waiting to get into=20 the conference.
4. = Moderator and=20 conferee passcode. I think the model calls this the = <conference-password>,=20 but there needs
to be = two, one for=20 moderator and one for conferee. Also as these are DTMF digits, I think = the term=20 'passcode'
is = more appropriate=20 than 'password'.
5. = Apart from the=20 access control lists, the model seems to be lacking in security, = specifically=20 there needs to be a
method to=20 specify PIN codes associated with a conference i.e. user needs to enter = this PIN=20 to gain entry to conference
6. Outbound=20 dial list is missing. Need to be able to configure URIs that the=20 moderator/operator can dial out to when conference=20 opens.
Also need to=20 configure how the people on the list get dialled e.g. manually by = operator or=20 automatic when moderator joins.
Need to=20 configure what message gets played to them initially=20 also.
7. Entry/Exit tone = configuration is=20 missing. Need to be able to specify what should get played when = particpants=20 enter/leave
e.g.=20 tone,message,tone&message,none 
 
General=20 questions:
1. How = would=20 on-demand conferences be modelled? (Demand conferences are conferences = that=20 people can dial into any time i.e. there would be no scheduling=20 information).
2. = There is no=20 mention of port/line pools. e.g. scheduled conferences would typically = use ports=20 from a reserved pool so one is guaranteed to get into the=20 conference
at = conference start=20 time. I think there should be an attribute to specify what pool to use - = reserved,unreserved,other.
3. For = recurring=20 conferences, where does the original recurrence info get stored? i.e. = there is a=20 <conference-time> entry for each recurrence which I=20 assume
will = have the=20 start/end timing info for that particular recurrence, but where does the = original pattern get stored and how does the model maintain the=20 releationship
between the=20 conferences that make up the pattern? This relationship would be handy = to apply=20 a modification to all conferences that make up a recurrence=20 pattern.
 
Sean
------_=_NextPart_001_01C8DC36.622FCB06-- --===============1282755370== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon --===============1282755370==-- From xcon-bounces@ietf.org Wed Jul 2 08:05:13 2008 Return-Path: X-Original-To: xcon-archive@megatron.ietf.org Delivered-To: ietfarch-xcon-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF3C73A6C4F; Wed, 2 Jul 2008 08:05:13 -0700 (PDT) X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90D3C3A6BD4 for ; Wed, 2 Jul 2008 08:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45d63CP9VSyZ for ; Wed, 2 Jul 2008 08:05:11 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 36AA13A6C17 for ; Wed, 2 Jul 2008 08:05:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,737,1204520400"; d="scan'208,217";a="113435143" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Jul 2008 11:05:15 -0400 X-IronPort-AV: E=Sophos;i="4.27,737,1204520400"; d="scan'208,217";a="227899214" Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.151]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Jul 2008 11:05:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Jul 2008 16:02:15 +0100 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F714DC080@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] draft-ietf-xcon-common-data-model Thread-Index: Acjamnjp9/SPqcBJRvCsEMWbxTmDMwBjZbrwAAsjT24= References: <4408C6EC74CC3D42824FD68FDA8E8F717EE5B8@306900ANEX2.global.avaya.com> From: "Duddy, Sean (Sean)" To: "Oscar Novo" , Subject: Re: [XCON] draft-ietf-xcon-common-data-model X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0099913745==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0099913745== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8DC55.073BF851" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8DC55.073BF851 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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.=20 Specifically I am talking about:- =20 1. 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... 2. Demand conferences On Demand conferences are an industry wide recognised type of = conference and therefore should be part of the model.=20 3. The pool/lines pool is not specific to PSTN. It is applicable to VOIP = also and not the same as . Basically they are used to divide up conferencing capacity. e.g. = scheduled conferences would typically use one pool and=20 demand another in order to guarantee resources for the scheduled ones... =20 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. =20 Sean ________________________________ From: Oscar Novo [mailto:oscar.novo@ericsson.com] Sent: Wed 02/07/2008 12:25 To: Duddy, Sean (Sean); xcon@ietf.org Subject: RE: [XCON] draft-ietf-xcon-common-data-model Sean, =20 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.=20 =20 Regarding your comment number 4, the and = 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 = 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 element and its 'method 'attribute.=20 =20 Answering your general questions briefly: =20 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 element.=20 Number 2: The pool/lines pool is quiet specific to PSTN. The data model = defines the element that it could be used for the = same purpose. Extension to this element can be done later.=20 Number 3: The information for recurring conference can be defined in the = 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@example.com ORGANIZER:MAILTO:carol@example.com DTSTART:20071017T143000Z RRULE:FREQ=3DWEEKLY DTEND:20071217T163000Z END:VEVENT END:VCALENDAR =20 Cheers, =20 Oscar ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Duddy, Sean (Sean) Sent: 30. kes=E4kuuta 2008 13:17 To: xcon@ietf.org Subject: [XCON] draft-ietf-xcon-common-data-model Hi, Some comments on the content of this data model re: audio = conferencing=20 (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) =20 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 = , but there needs=20 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=20 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=20 e.g. tone,message,tone&message,none=20 =20 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 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. =20 Sean ------_=_NextPart_001_01C8DC55.073BF851 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
=0A=
Hi = Oscar,
=0A=
   Thanks for your = reply. I am concerned that some key conferencing data items are missing = from the model and instead addressed via extensions.
=0A=
Specifically I am talking = about:-
=0A=
 
=0A=
1. = <conference-password.>
=0A=
    This is a = one-one mapping with the conference URI. Based on the IETF 68 minutes = Re:policies, why is this field still there?
=0A=
Basically every conference = needs at least two passwords - one for particpants  & one or = more for moderators.
=0A=
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...
=0A=
2. Demand = conferences
=0A=
   On Demand = conferences are an industry wide recognised type of conference and = therefore should be part of the model.
=0A=
3. The pool/lines pool is not = specific to PSTN. It is applicable to VOIP also and not the same as = <maximun-user-count>.
=0A=
Basically they are used to = divide up conferencing capacity. e.g. scheduled conferences would = typically use one pool and
=0A=
demand another in order to = guarantee resources for the scheduled ones...
=0A=
 
=0A=
On the recurring conference, = the model doesnt seem to allow modfication of a particular instance in a = recurrence pattern.
=0A=
e.g. I have a weekly = recurring conference, on a Friday. However next Friday, the meeting = needs to be moved forward by an hour.
=0A=
How can this be achieved via = the model? It would be essential to be able to view/modify individual = instances of a conference.
=0A=
 
=0A=
Sean
=0A=

=0A=
=0A= From: Oscar Novo = [mailto:oscar.novo@ericsson.com]
Sent: Wed 02/07/2008 = 12:25
To: Duddy, Sean (Sean); xcon@ietf.org
Subject: = RE: [XCON] draft-ietf-xcon-common-data-model

=0A=
=0A=
Sean,
=0A=
 
=0A=
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.
=0A=
 
=0A=
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. 
=0A=
 
=0A=
Answering your general questions briefly:
=0A=
 
=0A=
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. =
=0A=
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.
=0A=
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:
=0A=

 PRODID:-//LlamaSpinner = Inc.//NONSGML = CamelCall//EN
 VERSION:2.0
 BEGIN:VEVENT
 DTSTAMP= :20071003T140728Z
 UID:20071003T140728Z-345FDA-carol@example.com<= BR> ORGANIZER:MAILTO:carol@example.com
 DTSTART:20071017T143= 000Z
 RRULE:FREQ=3DWEEKLY
 DTEND:20071217T163000Z<= /DIV>=0A=
 END:VEVENT
 END:VCALENDAR
<= /SPAN>=0A=
 
=0A=
Cheers,
=0A=
 
=0A=
Oscar
=0A=

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

=0A=
=0A=
=0A=
Hi,
=0A=
    Some comments on the = content of this data model re: audio conferencing =
=0A=
(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)
=0A=
 
=0A=
1. = Conference recording is missing. Need attribute(s) to indicate if = recording is allowed and how it is triggered (automatic or = manual)
=0A=
2. = Conference playback is missing. Need attribute to indicate if playback = is allowed.
=0A=
3. = Music source selection is missing. Need to be able to set the music = source to be played to particpants
=0A=
waiting to get into the conference.
=0A=
4. = Moderator and conferee passcode. I think the model calls this the = <conference-password>, but there needs
=0A=
to be = two, one for moderator and one for conferee. Also as these are DTMF = digits, I think the term 'passcode'
=0A=
is = more appropriate than 'password'.
=0A=
5. = Apart from the access control lists, the model seems to be lacking in = security, specifically there needs to be a
=0A=
method to specify PIN codes associated with a conference = i.e. user needs to enter this PIN to gain entry to = conference
=0A=
6. Outbound dial list is missing. Need to be = able to configure URIs that the moderator/operator can dial out to when = conference opens.
=0A=
Also need to configure how the people on the = list get dialled e.g. manually by operator or automatic when moderator = joins.
=0A=
Need to configure what message gets played to = them initially also.
=0A=
7. Entry/Exit tone = configuration is missing. Need to be able to specify what should = get played when particpants enter/leave
=0A=
e.g. = tone,message,tone&message,none 
=0A=
 
=0A=
General questions:
=0A=
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).
=0A=
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
=0A=
at = conference start time. I think there should be an attribute to specify = what pool to use - reserved,unreserved,other.
=0A=
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
=0A=
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
=0A=
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.
=0A=
 
=0A=
Sean
------_=_NextPart_001_01C8DC55.073BF851-- --===============0099913745== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon --===============0099913745==-- From xcon-bounces@ietf.org Thu Jul 3 06:40:51 2008 Return-Path: X-Original-To: xcon-archive@megatron.ietf.org Delivered-To: ietfarch-xcon-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 750A43A683F; Thu, 3 Jul 2008 06:40:51 -0700 (PDT) X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AAFC3A67A8 for ; Thu, 3 Jul 2008 06:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.648 X-Spam-Level: X-Spam-Status: No, score=-5.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkC8wgV67kYj for ; Thu, 3 Jul 2008 06:40:45 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A6ACB3A683F for ; Thu, 3 Jul 2008 06:40:44 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 284062089F; Thu, 3 Jul 2008 15:40:52 +0200 (CEST) X-AuditID: c1b4fb3c-aa894bb00000193b-c4-486cd6e3a123 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EC406208C3; Thu, 3 Jul 2008 15:40:51 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Jul 2008 15:41:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Jul 2008 15:41:28 +0200 Message-ID: In-Reply-To: <4408C6EC74CC3D42824FD68FDA8E8F714DC080@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] draft-ietf-xcon-common-data-model Thread-Index: Acjamnjp9/SPqcBJRvCsEMWbxTmDMwBjZbrwAAsjT24ALcjo8A== References: <4408C6EC74CC3D42824FD68FDA8E8F717EE5B8@306900ANEX2.global.avaya.com> <4408C6EC74CC3D42824FD68FDA8E8F714DC080@306900ANEX2.global.avaya.com> From: "Oscar Novo" To: "Duddy, Sean (Sean)" , X-OriginalArrivalTime: 03 Jul 2008 13:41:32.0626 (UTC) FILETIME=[812A9320:01C8DD12] X-Brightmail-Tracker: AAAAAA== Subject: Re: [XCON] draft-ietf-xcon-common-data-model X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0444836415==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0444836415== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8DD12.80F8E3E0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8DD12.80F8E3E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi again, =20 Some comments inline as [ON]. =20 Oscar ________________________________ From: Duddy, Sean (Sean) [mailto:duddy@avaya.com]=20 Sent: 2. hein=E4kuuta 2008 18:02 To: Oscar Novo; xcon@ietf.org Subject: 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.=20 Specifically I am talking about:- =20 1. 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... =20 [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 . =20 Note as well that the accepts more than one = occurence. So, the mapping of this element is one-to-many.=20 =20 2. Demand conferences On Demand conferences are an industry wide recognised type of = conference and therefore should be part of the model. =20 =20 [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.=20 =20 3. The pool/lines pool is not specific to PSTN. It is applicable to VOIP = also and not the same as . Basically they are used to divide up conferencing capacity. e.g. = scheduled conferences would typically use one pool and=20 demand another in order to guarantee resources for the scheduled ones... =20 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.=20 =20 [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. =20 =20 Sean ________________________________ From: Oscar Novo [mailto:oscar.novo@ericsson.com] Sent: Wed 02/07/2008 12:25 To: Duddy, Sean (Sean); xcon@ietf.org Subject: RE: [XCON] draft-ietf-xcon-common-data-model Sean, =20 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.=20 =20 Regarding your comment number 4, the and = 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 = 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 element and its 'method 'attribute.=20 =20 Answering your general questions briefly: =20 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 element.=20 Number 2: The pool/lines pool is quiet specific to PSTN. The data model = defines the element that it could be used for the = same purpose. Extension to this element can be done later.=20 Number 3: The information for recurring conference can be defined in the = 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@example.com ORGANIZER:MAILTO:carol@example.com DTSTART:20071017T143000Z RRULE:FREQ=3DWEEKLY DTEND:20071217T163000Z END:VEVENT END:VCALENDAR =20 Cheers, =20 Oscar ________________________________ From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of = Duddy, Sean (Sean) Sent: 30. kes=E4kuuta 2008 13:17 To: xcon@ietf.org Subject: [XCON] draft-ietf-xcon-common-data-model Hi, Some comments on the content of this data model re: audio = conferencing=20 (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) =20 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 = , but there needs=20 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=20 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=20 e.g. tone,message,tone&message,none=20 =20 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 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. =20 Sean ------_=_NextPart_001_01C8DD12.80F8E3E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 again,
 
Some=20 comments inline as [ON].
 
Oscar

From: Duddy, Sean (Sean)=20 [mailto:duddy@avaya.com]
Sent: 2. hein=E4kuuta 2008 = 18:02
To:=20 Oscar Novo; xcon@ietf.org
Subject: RE: [XCON]=20 draft-ietf-xcon-common-data-model

Hi = Oscar,
   Thanks for your = reply. I am=20 concerned that some key conferencing data items are missing from the = model and=20 instead addressed via extensions.
Specifically I am talking=20 about:-
 
1.=20 <conference-password.>
    This is a = one-one=20 mapping with the conference URI. Based on the IETF 68 minutes = Re:policies, why=20 is this field still there?
Basically every conference = needs at least=20 two passwords - one for particpants  & one or more for=20 moderators.
If these fields are going to = be provided=20 via some policy schema, then I think that needs to be somehow described = so there=20 is a common definition...
 
[ON]=20 After Chicago's IETF some discussions between SIMPLE and XCON WGs were = made to=20 analyzes the gaps between these two WGs. One document was created:=20 'An Analysis of Feature Parity Between XCON/SIMPLE-Based = Chatrooms and=20 Other Chatrooms'. According to that document, the XCON data model =  This=20 document propose some modificaitons in the XCON data model to fill the = gaps=20 between both working groups. One of the elements added was=20 <conference-password>.
 
Note=20 as well that the <conference-password> accepts more than one = occurence.=20 So, the mapping of this element is one-to-many.=20
 
 2. Demand = conferences
   On Demand = conferences=20 are an industry wide recognised type of conference and = therefore should be=20 part of the model.  
 
[ON] I didn't say the model doesn't support demand = conferences.=20 The data model does support demand conferences but it's up to the = implementor=20 how to implement them. The data model just give the 'tools' and = 'elements' to do=20 it. It's out of the scope of the document to explain the diferent = scenarios for=20 demand conferences.
 
3. The pool/lines pool is not = specific to=20 PSTN. It is applicable to VOIP also and not the same as=20 <maximun-user-count>.
Basically they are used to = divide up=20 conferencing capacity. e.g. scheduled conferences would typically use = one pool=20 and
demand another in order to = guarantee=20 resources for the scheduled ones...
 
On the recurring conference, = the model=20 doesnt seem to allow modfication of a particular instance in a = recurrence=20 pattern.
e.g. I have a weekly = recurring conference,=20 on a Friday. However next Friday, the meeting needs to be moved forward = by an=20 hour.
How can this be = achieved via the=20 model? It would be essential to be able to view/modify individual = instances of a=20 conference. 
 
[ON]  I'm not an ICal = expert but=20 ICal defines different exception operations for recurring conferences. = For=20 instance you could use EXDATE or EXRULE operation to limit a = recurring=20 conference. As well you can create CHILD and PARENT recurrences to = modify the=20 time in a conference. Another option could be to reeschedule your = conference.=20 Actually, this is a ICal issue, not a XCON data model=20 issue.
 
 
Sean

From: Oscar Novo=20 [mailto:oscar.novo@ericsson.com]
Sent: Wed 02/07/2008=20 12:25
To: Duddy, Sean (Sean); xcon@ietf.org
Subject: = RE:=20 [XCON] draft-ietf-xcon-common-data-model

Sean,
 
The=20 controls defined in the data model are really basic ones as we agreed in = the WG.=20 The controls you suggested in your e-mail can be added to the document = in future=20 extensions. Note that the data model is not specific to one protocol = (e.g. PSTN,=20 SIP), that's why many times the data model uses general naming in order = to=20 fullfil the requirements of all the protocols.
 
Regarding your comment number 4, the = <participant-passcode> and=20 <administrator-passcode> elements were defined in previous = versions of the=20 document. However, the WG decided (check the minutes from IETF 68) to = leave out=20 the common policy from the data model. The element=20 <conference-password> is used to specify the PIN code of the = conference.=20 So, your comment number 5 is fullfil with this element. Concerning your = comment=20 number 6, the data model does define a outbound dial list, check the=20 <allowed-users-list> element and its 'method=20 'attribute. 
 
Answering your general questions briefly:
 
Number=20 1: The definition of on-demand conference in the data model it depends = pretty=20 much from the implementor. One option it would be not to defined the = DTSTART and=20 the DTEND in the <base> element.
Number=20 2: The pool/lines pool is quiet specific to PSTN. The data model defines = the=20 <maximum-user-count> element that it could be used for the same = purpose.=20 Extension to this element can be done later.
Number=20 3: The information for recurring conference can be defined in the = <base>=20 element. I suggested you to check RFC 2445. For instance, the example = defined in=20 the data model is a recurring conference. Check the example=20 below:

 PRODID:-//LlamaSpinner Inc.//NONSGML=20 CamelCall//EN
 VERSION:2.0
 BEGIN:VEVENT
 DTSTAMP= :20071003T140728Z
 UID:20071003T140728Z-345FDA-carol@example.com<= BR> ORGANIZER:MAILTO:carol@example.com
 DTSTART:20071017T143= 000Z
 RRULE:FREQ=3DWEEKLY
 DTEND:20071217T163000Z<= /DIV>
 END:VEVENT
 END:VCALENDAR
<= /SPAN>
 
Cheers,
 
Oscar

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

Hi,
    Some comments on the = content of this=20 data model re: audio conferencing
(I know these could be accomodated using=20 extensions but maybe = they should be=20 part of the standard model as they do seem central to any conferencing=20 solution)
 
1. = Conference=20 recording is missing. Need attribute(s) to indicate if recording is = allowed and=20 how it is triggered (automatic or manual)
2. = Conference=20 playback is missing. Need attribute to indicate if playback is=20 allowed.
3. = Music source=20 selection is missing. Need to be able to set the music source to be = played to=20 particpants
waiting to get into=20 the conference.
4. = Moderator and=20 conferee passcode. I think the model calls this the = <conference-password>,=20 but there needs
to be = two, one for=20 moderator and one for conferee. Also as these are DTMF digits, I think = the term=20 'passcode'
is = more appropriate=20 than 'password'.
5. = Apart from the=20 access control lists, the model seems to be lacking in security, = specifically=20 there needs to be a
method to=20 specify PIN codes associated with a conference i.e. user needs to enter = this PIN=20 to gain entry to conference
6. Outbound=20 dial list is missing. Need to be able to configure URIs that the=20 moderator/operator can dial out to when conference=20 opens.
Also need to=20 configure how the people on the list get dialled e.g. manually by = operator or=20 automatic when moderator joins.
Need to=20 configure what message gets played to them initially=20 also.
7. Entry/Exit tone = configuration is=20 missing. Need to be able to specify what should get played when = particpants=20 enter/leave
e.g.=20 tone,message,tone&message,none 
 
General=20 questions:
1. How = would=20 on-demand conferences be modelled? (Demand conferences are conferences = that=20 people can dial into any time i.e. there would be no scheduling=20 information).
2. = There is no=20 mention of port/line pools. e.g. scheduled conferences would typically = use ports=20 from a reserved pool so one is guaranteed to get into the=20 conference
at = conference start=20 time. I think there should be an attribute to specify what pool to use - = reserved,unreserved,other.
3. For = recurring=20 conferences, where does the original recurrence info get stored? i.e. = there is a=20 <conference-time> entry for each recurrence which I=20 assume
will = have the=20 start/end timing info for that particular recurrence, but where does the = original pattern get stored and how does the model maintain the=20 releationship
between the=20 conferences that make up the pattern? This relationship would be handy = to apply=20 a modification to all conferences that make up a recurrence=20 pattern.
 
Sean
------_=_NextPart_001_01C8DD12.80F8E3E0-- --===============0444836415== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon --===============0444836415==-- From xcon-bounces@ietf.org Fri Jul 11 10:44:43 2008 Return-Path: X-Original-To: xcon-archive@megatron.ietf.org Delivered-To: ietfarch-xcon-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8DFB3A692B; Fri, 11 Jul 2008 10:44:43 -0700 (PDT) X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1863A692B for ; Fri, 11 Jul 2008 10:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4LMpyr4r4p4 for ; Fri, 11 Jul 2008 10:44:42 -0700 (PDT) Received: from mho-02-bos.mailhop.org (mho-02-bos.mailhop.org [63.208.196.179]) by core3.amsl.com (Postfix) with ESMTP id 4F8B33A6768 for ; Fri, 11 Jul 2008 10:44:42 -0700 (PDT) Received: from 24-107-152-122.dhcp.stls.mo.charter.com ([24.107.152.122] helo=alan-johnstons-powerbook-g4-17.local) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1KHMfz-0004XU-RQ; Fri, 11 Jul 2008 17:44:59 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.152.122 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+ux4BvAt4WhkxMAL/ud4PtzYLtGB5l7fQ= Message-ID: <48779C17.4090000@sipstation.com> Date: Fri, 11 Jul 2008 12:44:55 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: xcon@ietf.org Cc: Adam Roach Subject: [XCON] Agenda Requests for IETF-72 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org If you would like agenda time in Dublin, email Adam and myself indicating your name, the draft, and how much time you would like. Thanks, Alan co-chair XCON _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Jul 11 13:03:33 2008 Return-Path: X-Original-To: xcon-archive@megatron.ietf.org Delivered-To: ietfarch-xcon-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BF463A681F; Fri, 11 Jul 2008 13:03:33 -0700 (PDT) X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22ABE3A67DA for ; Fri, 11 Jul 2008 13:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5H2HngM+L997 for ; Fri, 11 Jul 2008 13:03:31 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 2B3703A681F for ; Fri, 11 Jul 2008 13:03:31 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m6BK3Y6S011357 for ; Fri, 11 Jul 2008 16:03:34 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m6BK3YCc234758 for ; Fri, 11 Jul 2008 16:03:34 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m6BK3YJ9031763 for ; Fri, 11 Jul 2008 16:03:34 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m6BK3YJS031756 for ; Fri, 11 Jul 2008 16:03:34 -0400 Auto-Submitted: auto-generated From: Zon-Yin Shae To: xcon@ietf.org Message-ID: Date: Fri, 11 Jul 2008 16:03:33 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.0.1|February 07, 2008) at 07/11/2008 16:03:33 MIME-Version: 1.0 Subject: [XCON] Zon-Yin Shae is out of the office. X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org I will be out of the office starting 07/07/2008 and will not return until 07/21/2008. I will respond to your message when I return. _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Jul 17 11:33:04 2008 Return-Path: X-Original-To: xcon-archive@megatron.ietf.org Delivered-To: ietfarch-xcon-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50C513A6AB8; Thu, 17 Jul 2008 11:33:04 -0700 (PDT) X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA1D3A6A3B for ; Thu, 17 Jul 2008 11:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHbMhoMDbJcj for ; Thu, 17 Jul 2008 11:33:03 -0700 (PDT) Received: from mho-01-bos.mailhop.org (mho-01-bos.mailhop.org [63.208.196.178]) by core3.amsl.com (Postfix) with ESMTP id 182A83A6AEA for ; Thu, 17 Jul 2008 11:33:03 -0700 (PDT) Received: from 71-10-181-211.dhcp.stls.mo.charter.com ([71.10.181.211] helo=alan-johnstons-powerbook-g4-17.local) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1KJYIH-000E1f-Sl for xcon@ietf.org; Thu, 17 Jul 2008 18:33:34 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.10.181.211 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18M+d5Vg1Bls6uGz5L2xYmamfralhvWBng= Message-ID: <487F9072.1000802@sipstation.com> Date: Thu, 17 Jul 2008 13:33:22 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: xcon@ietf.org Subject: [XCON] Draft Agenda for IETF-72 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org IETF-72 TUESDAY, July 29, 2008 1740-1840 Afternoon Session III Convention 3 RAI xcon Centralized Conferencing WG CHAIRS: Adam Roach Alan Johnston 1740 - 1745 Agenda Bash (Chairs) 5 minutes 1745 - 1750 Status (Chairs) 5 minutes 1750 - 1810 CCMP Protocol (Mary Barnes) 20 minutes http://tools.ietf.org/id/draft-ietf-xcon-ccmp-00.txt 1810 - 1825 Call Flows/Examples (Mary Barnes) 15 minutes http://tools.ietf.org/id/draft-barnes-xcon-examples-00.txt 1825 - 1835 CCMP Demo (Simon Romano) 5 minutes 1830 - 1840 Open Discussion 10 minutes Thanks, Alan _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon