From xcon-bounces@ietf.org Fri Jun 6 01:20:49 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 B76353A6AB4; Fri, 6 Jun 2008 01:20:49 -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 EC80E28C1B1 for ; Fri, 6 Jun 2008 01:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 VZzC1GfXSUQV for ; Fri, 6 Jun 2008 01:20:47 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id AF4C23A6AB4 for ; Fri, 6 Jun 2008 01:20:46 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5E9BC214DE; Fri, 6 Jun 2008 10:20:54 +0200 (CEST) X-AuditID: c1b4fb3e-af99bbb000004ec0-58-4848f3669b6f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 37CB420986; Fri, 6 Jun 2008 10:20:54 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jun 2008 10:20:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Jun 2008 10:20:53 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] WGLC: draft-ietf-xcon-common-data-model-10.txt Thread-Index: Aci1KcI/CJ5VIqPmSRmB0qP6hcoP8ABkoLKgBBEutKA= References: <48188FC8.4080909@nostrum.com> <4829E1DE.8000307@nostrum.com> From: "Oscar Novo" To: "Mary Barnes" , "XCON-IETF" X-OriginalArrivalTime: 06 Jun 2008 08:20:53.0820 (UTC) FILETIME=[3CCA7FC0:01C8C7AE] X-Brightmail-Tracker: AAAAAA== Cc: draft-ietf-xcon-common-data-model@tools.ietf.org Subject: Re: [XCON] WGLC: draft-ietf-xcon-common-data-model-10.txt 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 Hi Mary, Thanks for your comments. Inline you have my answer as a [ON] Cheers, Oscar ------------------------------------------------------------------------ ------------------------------------------------------------- I have reviewed the diff of the -10 against the last version I reviewed in detail (-08) and have just one general question, a few comments and one nit. Overall, I think the document is ready to progress. Regards, Mary. Question: ---------- I did have one general question as to whether this version incorporates the additional media fields that were identified by the MEDIACTRL folks? [ON] I discussed privately with Scott McGlashan about these changes in the last IETF. This fields were identified and I sent to the mailing list the decision to get consensus. You can check from the XCON archives my email sent it on 28 Mar 2008. Comments: --------- S4 and S5: While working on the details for the protocol, I realized we need a couple more elements added to including an element to reflect if this conference is a "parent" and/or a "child" and the "parent" of a "child" conference and the "child"ren of the "parent" conferences and whether the "child" is "independent" from the "parent". I think we can do that by defining the following: - "parent" element that can hold the XCON-URI for the parent and a boolean as to whether the child is "independent" of the parent. - "child" attribute that contains a set of XCON-URIs, one for each child obviously. [ON] I think to add elements for the protocol is to act rashly at this moment. The protocol is under discussion and still is too early to take thing for granted. I would recommend to extend the data model if it's needed later on in a more stable phase. Note, as well, the sidebars elements define the subconferences in a conference. S4.1/p13, 3rd sentence. For some reason, it is no longer clear to me why we wouldn't want "state" and "version" as part of the , as XCON will also support notifications, if I understand this sentence correctly: "Note that the element does not have the attributes 'state' and 'version' defined in [RFC4575] for this element because these attributes only applies to notification mechanisms." (also note the NIT in that sentence below) [ON] The data model only defines the information in the conference. However, RFC 4575 not only define the information in a conference but the elements used in the notification mechanism as well. The "state" and "version" elements are used for notifications, consequently, they are not defined as part of the conference information in the data model. S.4.6.5/p24, 3rd sentence. Same point as above wrt "state". [ON] Ditto Nits: ----- S4.1/p13, 3rd sentence: "applies" -> "apply" [ON] Thanks, I'll fix that typo. _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Jun 6 07:11:18 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 C8ED93A6D71; Fri, 6 Jun 2008 07:11:18 -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 6A03F3A68F6 for ; Fri, 6 Jun 2008 01:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 08lisU3MRO1y for ; Fri, 6 Jun 2008 01:20:21 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6D5A33A6910 for ; Fri, 6 Jun 2008 01:20:20 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F186720D55; Fri, 6 Jun 2008 10:20:27 +0200 (CEST) X-AuditID: c1b4fb3c-ae89cbb00000193b-73-4848f34b359b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id ABA2D20EB8; Fri, 6 Jun 2008 10:20:27 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jun 2008 10:20:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Jun 2008 10:20:26 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] WGLC: draft-ietf-xcon-common-data-model-10.txt Thread-Index: Aci3aEfQHyiMj9+RT2KCNQo7uQ38/wQO+a4w References: From: "Oscar Novo" To: "Connolly, Stephen (Stephen)" , "XCON-IETF" X-OriginalArrivalTime: 06 Jun 2008 08:20:27.0243 (UTC) FILETIME=[2CF32BB0:01C8C7AE] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Fri, 06 Jun 2008 07:11:18 -0700 Cc: "Johnston, Alan B \(Alan\)" , draft-ietf-xcon-common-data-model@tools.ietf.org Subject: Re: [XCON] WGLC: draft-ietf-xcon-common-data-model-10.txt 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="===============1945934089==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1945934089== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C7AE.2CEBAD38" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C7AE.2CEBAD38 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi guys, =20 Thank you very much for you comments and sorry for my late reply. I've been on holidays all this time. Comments inline as [ON] =20 Cheers, =20 Oscar ________________________________ From: Connolly, Stephen (Stephen) [mailto:connollys@avaya.com]=20 Sent: 16. toukokuuta 2008 18:20 To: XCON-IETF Cc: draft-ietf-xcon-common-data-model@tools.ietf.org; Johnston, Alan B (Alan) Subject: Re: [XCON] WGLC: draft-ietf-xcon-common-data-model-10.txt All, =20 Here are our consolidated comments while wearing our "Avaya" hats. =20 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? =20 [ON] The data model is extensible. Proprietary elements can be added in future extensions. Check section 6 of the draft. =20 =20 pg14, S4.2.1=20 * this assumes only a specific language is available, what about country variants and fallback e.g. en, en_gb=20 =20 [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.=20 =20 pg 15, S4.2.6=20 * Does this imply a default of false if not specified ? =20 =20 [ON] This is up to local policy. =20 What about size of sidebars, number of sidebars=20 =20 [ON] We decided to leave this information out of the data model. Always is possible to add it in some extensions. =20 pg 15, S4.2.7=20 * Does their need to be anything about demand / scheduled / adhoc (tui)=20 =20 [ON] Possible to add it in some extensions if you need it. =20 * 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?=20 =20 [ON] The data model only defines the information in a conference. How to handle this information is up to every implementor. =20 * Should there be a way of linking via a uri to the ical object the base element under conference-time\entry.=20 =20 * 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.=20 =20 [ON] I recommend you to check RFC 2445.=20 =20 * required-participant attribute under mixing-start-offset has no apparent definitions of the various roles=20 =20 [ON] The definitions of the roles is out of scope of this document. =20 * can-join-after-offset doesn't mention DTSTART and signed integer=20 =20 [ON] It's similar to but I'll add it to make it clear.=20 =20 * allowed-extend-mixing-end-offset has no apparent limits on size, duration , number of extension periods=20 =20 [ON] it's open to future extensions =20 * Would there be a requirement for accessing current time and tz on server. How would one handle a distributed / dispersed server deployment? =20 [ON] this is out of scope of this document.=20 =20 * In the Schema, the *-offset elements are dates, while in this section they are described as integer offsets=20 =20 [ON] I'll fix that in the text. =20 =20 pg 16, S4.2.8=20 * 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 =20 [ON] We already discussed that in IETF-69 and the WG consensus was to have one element type.=20 =20 * There is only one element. We have at least two levels of password and can have multiple passwords for the same level. How would this be represented?=20 =20 [ON] I'll extend the schema to accept this case.=20 =20 pg17, S4.2.10 * would S4.2.10 depend on S4.2.11, and is there a way to capture that dependency=20 =20 [ON] up to the implementor.=20 =20 * Does this maximum user count refer to the maximum users supported by the media mixing servers, or the limit for the conference? =20 [ON] The maximum users allowed to join the conference.=20 =20 * Is there any way to indicate that the maximum-user-count can be increased on demand if necessary?=20 =20 [ON] not now but you could extend it later.=20 =20 pg 18, S4.2.11=20 * No mention of data, whileboarding. Need a way to indicate bandwidth, preferred audio / image formats.=20 =20 [ON] the data model only defined basic media: audio and video.=20 =20 * What type of does 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. =20 [ON] this element only describes the cease of audio but it does not differentiate who has the right to applied or remove it.=20 =20 * How can other controls be exposed? =20 =20 pg19, S4.3=20 * Failover scenario - tcp-ip possibly changes=20 =20 [ON] I don't understand what's the problem here=20 =20 pg 19, S4.4=20 * Is this data model only concerned with runtime info? If not need a way to indicate cancelled, billed, aborted, confirmed and possibly other states=20 =20 [ON] check the and elements, section 4.4.3 and 4.4.4 =20 pg 22, S4.6=20 * Presumably user can have multiple roles simultaneously. =20 =20 [ON] are you talking about 4.6.5.4 section? Section 4.6 doesn't defined any role.=20 =20 pg23, S4.6.3=20 * No definition of roles, format of uris=20 =20 [ON] i'll add them in the text. =20 pg 24, S4.6.4=20 * No definition of roles, format of uris=20 =20 [ON] idem=20 =20 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=20 =20 [ON] up to the implementor. =20 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. =20 [ON] check RFC4582 for this questions. =20 pg28, S4.6.5.10=20 * Data, whiteboarding in the from mixer element=20 =20 [ON] the data model only defined basic media: audio and video.=20 =20 pg28, S5=20 * This section duplicates Appendix A., shouldn't the schema be defined in one location only in order to reduce the posibility of synchronization errors=20 =20 [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. =20 =20 pg29, conference-description-type * Extend to allow multiple conference-password child elements=20 =20 [ON] I'll add this in the schema. =20 pg33, Conference-floor-policy * Should begin with a "c" not a "C"=20 =20 [ON] It's only a tag element in the schema but I can modify it. =20 =20 * Need the ability to have multiple moderator-id's controlling the floor. =20 [ON] I can add this in the schema. ------_=_NextPart_001_01C8C7AE.2CEBAD38 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 guys,
 
Thank=20 you very much for you comments and sorry for my late reply. I've been on = holidays all this time. Comments inline as [ON]
 
Cheers,
 
Oscar

From: Connolly, Stephen (Stephen)=20 [mailto:connollys@avaya.com]
Sent: 16. toukokuuta 2008=20 18:20
To: XCON-IETF
Cc:=20 draft-ietf-xcon-common-data-model@tools.ietf.org; Johnston, Alan B=20 (Alan)
Subject: Re: [XCON] WGLC:=20 draft-ietf-xcon-common-data-model-10.txt

All,
 
Here are our consolidated comments while = wearing our=20 "Avaya" hats.
 
pg13, Figure 3 & pg 14, = S4.2
*   =20 Where do generic / proprietary conference attributes fit in = e.g.=20 pin-list, recording, billing, call flow type , biometric , data, video , = annunicator msgs?
 
[ON] The data model is extensible. Proprietary = elements can be=20 added in future extensions. Check section 6 of the=20 draft.
 
 
pg14, S4.2.1 =
*    this assumes only = a specific=20 language is available, what about country variants and fallback e.g. en, = en_gb 
 
[ON] The language = datatype=20 accepts strings that are conforming with RFC3066bis and RFC4646 and = these drafts=20 accepts country variants and many other possibilities. I recommend you = to check=20 these RFC. 
 
pg 15, S4.2.6 
*    Does this imply a = default of=20 false if not specified ?  
 
[ON] This is up to local=20 policy.
 
 What about size of sidebars, = number of=20 sidebars 
 
[ON] We decided to leave this = information=20 out of the data model. Always is possible to add it in some=20 extensions.
 
pg 15, S4.2.7 
*    Does their need to = be=20 anything about demand / scheduled / adhoc (tui) 
 
[ON] Possible to add it in some extensions if = you need=20 it.
&nbs= p;
*    Mandate all date = times in=20 UTC. It's up to a client application to convert to / from local = time as=20 appropriate. How to handle timezones and variation in dst rules or is = this a=20 problem for the OS and main userspace runtime library? 
 
[ON] The data = model only=20 defines the information in a conference. How to handle this information = is up to=20 every implementor.
 
*    Should there be a = way of=20 linking via a uri to the ical object the base element under=20 conference-time\entry.
 
*    I'm not familiar = enough with=20 ical rfc, but can it specify perpetual conferences, recurring series = with odd=20 exceptions ? Tz / dst changes that are outside normal rules due to = political=20 changes. 
 
[ON] I recommend you to = check RFC=20 2445. 
 
*    = required-participant=20 attribute under mixing-start-offset has no apparent definitions of the = various=20 roles 
 
[ON] The = definitions of the=20 roles is out of scope of this = document.
 
*    = can-join-after-offset=20 doesn't mention DTSTART and signed integer 
 
[ON] It's similar=20 to <must-join-before-offset> but I'll add it to make it clear.=20
 
*   =20 allowed-extend-mixing-end-offset has no apparent limits on size, = duration=20 , number of extension periods 
 
[ON] it's open to future=20 extensions
 
*    Would there be a = requirement=20 for accessing current time and tz on server. How would one handle a = distributed=20 / dispersed server deployment?
 
[ON] this is out of scope of this document.=20
 
*    In the Schema, the = *-offset elements=20 are dates, while in this section they are described as integer = offsets 
 
[ON]=20 I'll fix that in the text.=20  
 
pg 16, S4.2.8 =
*   =20 Must be able to repesent = multiple=20 access numbers to same logical conference e.g. international, toll free, = local=20 access for PSTN users. Howto represent a conference which spans multiple = dispersed bridges
 
[ON] We already discussed that in IETF-69 and = the WG=20 consensus was to have one element type.=20
 
*    There is only one=20 <conference-password> element.  We have at least two levels = of=20 password and can have multiple passwords for the same level. How would = this be=20 represented? 
 
[ON] I'll extend the schema to accept this=20 case. 
 
pg17, S4.2.10
*    would S4.2.10 depend on = S4.2.11, and=20 is there a way to capture that dependency 
 
[ON] up to the=20 implementor. 
 
*    Does this maximum user count = refer to the=20 maximum users supported by the media mixing servers, or the limit for = the=20 conference?
 
[ON] The maximum = users allowed=20 to join the conference.
 
*    Is there any way to = indicate that=20 the maximum-user-count can be increased on demand if necessary? 
 
[ON]=20 not now but you could extend it=20 later. 
 
pg 18, S4.2.11 
*    No mention of = data,=20 whileboarding. Need a way to indicate bandwidth, preferred audio / image = formats. 
 
[ON] the data model = only defined=20 basic media: audio and = video. 
 
*    What type of <mute> = does=20 <mute> provide.  We differentiate two types of mute: "mute" = is a mute=20 that can be applied by a moderator or by yourself.  It can only be = removed=20 by yourself. "silence" is a mute that can only be applied or removed by = a=20 moderator.
 
[ON] this = element only=20 describes the cease of audio but it does not differentiate who has the = right to=20 applied or remove it.
 
*    How can other = controls be=20 exposed?   
 
pg19, S4.3
*    Failover scenario - tcp-ip possibly = changes 
 
[ON] I don't understand = what's the=20 problem here 
 
pg 19, S4.4 =
*   =20 Is this data model only concerned with runtime info? If not need = a way to=20 indicate cancelled, billed, aborted, confirmed and possibly other = states 
 
[ON] check the = <locked> and=20 <active> elements, section 4.4.3 = and=20 4.4.4
 
pg 22, S4.6 =
*   =20 Presumably user can have multiple roles = simultaneously.  
 
[ON] are you talking = about 4.6.5.4=20 section? Section 4.6 doesn't defined any role.=20
 
pg23, S4.6.3 =
*    No definition of roles, format of uris 
 
[ON] i'll add them in the=20 text.
 
pg 24, S4.6.4 =
*   =20 No = definition of roles,=20 format of uris 
 
[ON]=20 idem 
 
pg 24, = S4.5.0
*    How are user PINs = represented, i.e.=20 the number unique to each user that allows them to identify themselves = via the=20 TUI after entering the conference password 
 
[ON] up to the = implementor.
 
pg 27, = S4.6.5.10
*    Can multiple users hold = the floor=20 in the same floor at the same time? Can a user hold multiple floors at the same = time? An=20 example of these would be good.
 
[ON] check RFC4582 for this=20 questions.
 
pg28, S4.6.5.10
*   =20 Data, whiteboarding in the from mixer element 
 
[ON] the data model only defined basic media: audio and=20 video. 
 
pg28, = S5 
*    This section = duplicates=20 Appendix A., shouldn't the = schema be=20 defined in one location only in order = to reduce=20 the posibility of synchronization errors 
 
[ON]=20 One schema is generated using the other. That's a WG consensus to make = it more=20 understandable for the reader. The possibility of synchronization errors = are=20 minimal.
 
 
pg29,=20 conference-description-type
*    Extend to allow multiple = conference-password child=20 elements 
 
[ON]  I'll add this in the=20 schema.
 
pg33,=20 Conference-floor-policy
*    Should begin with a "c" not a "C" 
 
[ON] It's only a tag element in the schema = but I can=20 modify it.
 
 
*   =20 Need the ability to have multiple moderator-id's controlling the=20 floor.
 
[ON] I can add this in the=20 schema.
------_=_NextPart_001_01C8C7AE.2CEBAD38-- --===============1945934089== 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 --===============1945934089==-- From xcon-bounces@ietf.org Mon Jun 9 15:16:29 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 733193A6AD5; Mon, 9 Jun 2008 15:16:29 -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 9137E3A6A6A; Mon, 9 Jun 2008 15:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.718 X-Spam-Level: X-Spam-Status: No, score=-16.718 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] 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 QcXVQD5C6n-0; Mon, 9 Jun 2008 15:16:27 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id AA8E63A68C1; Mon, 9 Jun 2008 15:16:27 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 11BA9135F53; Mon, 9 Jun 2008 15:16:48 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20080609221648.11BA9135F53@bosco.isi.edu> Date: Mon, 9 Jun 2008 15:16:48 -0700 (PDT) Cc: xcon@ietf.org, rfc-editor@rfc-editor.org Subject: [XCON] RFC 5239 on A Framework for Centralized Conferencing 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5239 Title: A Framework for Centralized Conferencing Author: M. Barnes, C. Boulton, O. Levin Status: Standards Track Date: June 2008 Mailbox: mary.barnes@nortel.com, cboulton@avaya.com, oritl@microsoft.com Pages: 57 Characters: 146927 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-xcon-framework-11.txt URL: http://www.rfc-editor.org/rfc/rfc5239.txt This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber, Q.931 or ISDN User Part (ISUP), to exchange media in a centralized unicast conference. The Centralized Conferencing Framework defines logical entities and naming conventions. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems. [STANDARDS TRACK] This document is a product of the Centralized Conferencing Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Jun 12 03:15: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 1217228C0F0; Thu, 12 Jun 2008 03:15:04 -0700 (PDT) X-Original-To: xcon@ietf.org Delivered-To: xcon@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 10B6E3A6A4E; Thu, 12 Jun 2008 03:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080612101502.10B6E3A6A4E@core3.amsl.com> Date: Thu, 12 Jun 2008 03:15:02 -0700 (PDT) Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-common-data-model-11.txt 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: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Conference Information Data Model for Centralized Conferencing (XCON) Author(s) : O. Novo, et al. Filename : draft-ietf-xcon-common-data-model-11.txt Pages : 75 Date : 2008-06-12 This document defines an Extensible Markup Language (XML)-based conference information data model for centralized conferencing (XCON). A conference information data model is designed to convey information about the conference and about participation in the conference. The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) Event Package for Conference State. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xcon-common-data-model-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-12030357.I-D@ietf.org> --NextPart 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 --NextPart-- From xcon-bounces@ietf.org Thu Jun 12 03:29: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 9076D3A69E4; Thu, 12 Jun 2008 03:29: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 1DFAF3A6A1C for ; Thu, 12 Jun 2008 03:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 lJaJ8LC7D6Qy for ; Thu, 12 Jun 2008 03:29:05 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B75F13A69E4 for ; Thu, 12 Jun 2008 03:29:04 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 91A95221D7; Thu, 12 Jun 2008 12:26:46 +0200 (CEST) X-AuditID: c1b4fb3c-ad099bb00000193b-ca-4850f9e6e40c Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 77275221DB; Thu, 12 Jun 2008 12:26:46 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 12:26:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Jun 2008 12:26:49 +0200 Message-ID: In-Reply-To: <20080612101502.10B6E3A6A4E@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version for draft-ietf-xcon-common-data-model-11 Thread-Index: AcjMda6EU4aB8K8IQE2FHgomcDqpPQAALyAg References: <20080612101502.10B6E3A6A4E@core3.amsl.com> From: "Oscar Novo" To: , "Adam Roach" , "Alan Johnston" X-OriginalArrivalTime: 12 Jun 2008 10:26:52.0791 (UTC) FILETIME=[D4C47070:01C8CC76] X-Brightmail-Tracker: AAAAAA== Subject: [XCON] New version for draft-ietf-xcon-common-data-model-11 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Hi guys, A new version of the data model including the comments from the WGLC is ava= ilable in the IETF directories. Cheers, Oscar -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Int= ernet-Drafts@ietf.org Sent: 12. kes=E4kuuta 2008 13:15 To: i-d-announce@ietf.org Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-common-data-model-11.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Centralized Conferencing Working Group of = the IETF. Title : Conference Information Data Model for Centralized Confer= encing (XCON) Author(s) : O. Novo, et al. Filename : draft-ietf-xcon-common-data-model-11.txt Pages : 75 Date : 2008-06-12 This document defines an Extensible Markup Language (XML)-based conference = information data model for centralized conferencing (XCON). A conference i= nformation data model is designed to convey information about the conferenc= e and about participation in the conference. The conference information da= ta model defined in this document constitutes an extension of the data form= at specified in the Session Initiation Protocol (SIP) Event Package for Con= ference State. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ XCON mailing list XCON@ietf.org https://www.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Jun 16 17:30: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 8C3AB28C16C; Mon, 16 Jun 2008 17:30:07 -0700 (PDT) X-Original-To: xcon@ietf.org Delivered-To: xcon@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 52A043A6806; Mon, 16 Jun 2008 17:30:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080617003004.52A043A6806@core3.amsl.com> Date: Mon, 16 Jun 2008 17:30:04 -0700 (PDT) Cc: xcon@ietf.org Subject: [XCON] I-D Action:draft-ietf-xcon-ccmp-00.txt 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: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Centralized Conferencing Manipulation Protocol Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-ccmp-00.txt Pages : 42 Date : 2008-06-16 The Centralized Conferencing Manipulation Protocol (CCMP) defined in this document provides the mechanisms to create, change and delete objects related to centralized conferences, including participants, their media and their roles. The protocol relies on web services as its infrastructure, but can control conferences that use any signaling protocol to invite users. CCMP is based on the Simple Object Access Protocol (SOAP), with the data necessary for the interactions specified via Web Services Description Language (WSDL). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-ccmp-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-xcon-ccmp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-06-16172053.I-D@ietf.org> --NextPart 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 --NextPart-- From xcon-bounces@ietf.org Thu Jun 19 12:27:23 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 57BF43A694C; Thu, 19 Jun 2008 12:27:23 -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 A08A328C0CE for ; Thu, 19 Jun 2008 12:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[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 c2IB51QKefPh for ; Thu, 19 Jun 2008 12:27:20 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 80DB23A694C for ; Thu, 19 Jun 2008 12:27:20 -0700 (PDT) Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m5JJRHL24298 for ; Thu, 19 Jun 2008 19:27:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8D242.744A2435" Date: Thu, 19 Jun 2008 14:24:27 -0500 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-xcon-ccmp-00.txt Thread-Index: AcjQEckGJDdXK+abSF2Qqem1edOA6QCLcKIA From: "Mary Barnes" To: "XCON-IETF" Subject: [XCON] FW: I-D Action:draft-ietf-xcon-ccmp-00.txt 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: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D242.744A2435 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This document is the WG version derived from draft-barnes-xcon-ccmp-04, that was discussed at IETF-71 and agreed as the basis for the WG protocol document.=20 We have updated the document based on the feedback that the protocol should define more discrete messages rather than just adding additional parameters to the existing messages. The previous version just had a single request/response containing an operation. We've kept the concept of operation as a parameter, but the detailed processing and parameters for the operation can vary depending upon the type of request.=20 We would like WG feedback on the following points (and of course, any other comments you might have): 1. The general document structure - we'd rather change that now rather than later.=20 2. The general protocol structure, highlighted above and hopefully fairly well documented in this version. 3. Other discrete operations that should be defined for the initial protocol version. 4. Feedback related to "Editor's notes:" in the document.=20 Simon Pietro Romano has joined as a co-author - his input has been extremely useful based on his experiences with the prototype he and his associates demonstrated at a previous IETF (which included the floor control and was based on a very early version of CCMP). Simon is already in the process of updating their prototype based on the most recent data model to incorporate some of the concepts we've defined in this protocol document. So, hopefully, we'll have running code as we develop this document.=20 We are also in the process of putting together a call flow document (with details to be derived from the prototype) , per discussions from IETF-71, again working with Simon and his associates. The call flows should also help us to validate the technical content of this document, as well as to ensure consistency with the XCON FW. We'll be starting with the scenarios from that document, as many of those scenarios were derived from the XCON scenarios document - RFC 4597. The plan is to produce an initial version prior to IETF-72. Thanks, Mary, Chris, Henning and Simon.=20 -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, June 16, 2008 7:30 PM To: i-d-announce@ietf.org Cc: xcon@ietf.org Subject: I-D Action:draft-ietf-xcon-ccmp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Centralized Conferencing Manipulation Protocol Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-ccmp-00.txt Pages : 42 Date : 2008-06-16 The Centralized Conferencing Manipulation Protocol (CCMP) defined in this document provides the mechanisms to create, change and delete objects related to centralized conferences, including participants, their media and their roles. The protocol relies on web services as its infrastructure, but can control conferences that use any signaling protocol to invite users. CCMP is based on the Simple Object Access Protocol (SOAP), with the data necessary for the interactions specified via Web Services Description Language (WSDL). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-ccmp-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C8D242.744A2435 Content-Type: application/octet-stream; name="draft-ietf-xcon-ccmp-00.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-xcon-ccmp-00.URL Content-Disposition: attachment; filename="draft-ietf-xcon-ccmp-00.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXhjb24tY2NtcC0wMC50eHQNCg== ------_=_NextPart_001_01C8D242.744A2435 Content-Type: text/plain; name="ATT1554850.txt" Content-Transfer-Encoding: base64 Content-Description: ATT1554850.txt Content-Disposition: attachment; filename="ATT1554850.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01C8D242.744A2435 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 ------_=_NextPart_001_01C8D242.744A2435-- From xcon-bounces@ietf.org Mon Jun 30 03:17:15 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 B885D3A67FB; Mon, 30 Jun 2008 03:17:15 -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 C7A903A6778 for ; Mon, 30 Jun 2008 03:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6] 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 CNwMADe8bssN for ; Mon, 30 Jun 2008 03:17:13 -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 22C8A3A67FB for ; Mon, 30 Jun 2008 03:17:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,727,1204520400"; d="scan'208,217";a="113080723" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 30 Jun 2008 06:17:22 -0400 X-IronPort-AV: E=Sophos;i="4.27,727,1204520400"; d="scan'208,217";a="226405904" Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.151]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 Jun 2008 06:17:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Jun 2008 11:17:16 +0100 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F717EE5B8@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-xcon-common-data-model Thread-Index: Acjamnjp9/SPqcBJRvCsEMWbxTmDMw== From: "Duddy, Sean (Sean)" To: Subject: [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="===============1978309813==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1978309813== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8DA9A.7AC8AD34" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8DA9A.7AC8AD34 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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_01C8DA9A.7AC8AD34 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
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_01C8DA9A.7AC8AD34-- --===============1978309813== 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 --===============1978309813==-- From xcon-bounces@ietf.org Mon Jun 30 07:46:21 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 E2DC73A684E; Mon, 30 Jun 2008 07:46:20 -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 6CC493A6819 for ; Mon, 30 Jun 2008 07:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 ptyGoAVlp8Jc for ; Mon, 30 Jun 2008 07:46:18 -0700 (PDT) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 562E23A68F7 for ; Mon, 30 Jun 2008 07:46:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,727,1204520400"; d="scan'208,217";a="133510500" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 30 Jun 2008 10:46:22 -0400 X-IronPort-AV: E=Sophos;i="4.27,727,1204520400"; d="scan'208,217";a="219739528" Received: from unknown (HELO 306900ANEX2.global.avaya.com) ([135.64.148.151]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 30 Jun 2008 10:46:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Jun 2008 15:46:14 +0100 Message-ID: <4408C6EC74CC3D42824FD68FDA8E8F717EE69B@306900ANEX2.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-xcon-ccmp Thread-Index: AcjawAvrD2XQ8oDNRgucGz6qu3ARnw== From: "Duddy, Sean (Sean)" To: Subject: [XCON] draft-ietf-xcon-ccmp 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="===============1324697684==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1324697684== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8DAC0.0FEAF5C0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8DAC0.0FEAF5C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, some comments on the draft-ietf-xcon-ccmp-00=20 =20 1. 6.1 Conference Object Blueprints are mentioned in the ccmp doc but are are not mentioned in the draft-ietf-xcon-common-data-model-11.txt data model.=20 It is unclear how the relationship between 'real conferences' (those with resources allocated to it) and blueprints is maintained in the model. e.g. can one query all the conferences derived from a blueprint? (might be useful if one wanted to see the effect of modifying a blueprint) =20 2. 7.1 Retrieve Is it possible to retrieve conferences based on serach criteria? and considering the result set could=20 potentially run into the 1000s, should a paging mechanism be proposed in the SOAP interface? =20 3. Options Request The purpose of this request is not very clear, maybe the cmd is not named very well. In any case, the usage of this cmd should be in the 'Examples' section also. So basically from what I gather, this cmd=20 is used by the client to determine what namespaces the server understands and their associated blueprints? It also states=20 =20 optionsRequest/optionsResponse: The optionsRequest is used to ascertain the namespaces, conference reservations and active conferences supported by the server. The optionsResponse returns a list of the requested types of conference objects (e.g., Blueprints, Conference Reservations and/or Active Confrences) supported by the specific conference server. I dont understand why this cmd would be used to return active conferences also? Should that be a seperate cmd? =20 Sean =20 =20 =20 =20 ------_=_NextPart_001_01C8DAC0.0FEAF5C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
   =20 some comments on the draft-ietf-xcon-ccmp-00=20
 
1. 6.1 Conference=20 Object
    Blueprints are mentioned = in the ccmp=20 doc but are are not mentioned in the = draft-ietf-xcon-common-data-model-11.txt=20 data model.
It is unclear how the relationship between=20 'real conferences' (those with = resources=20 allocated to it)  and blueprints is maintained in the=20 model.
e.g. can one query all the conferences = derived from a=20 blueprint? (might be useful if one wanted to see the effect of modifying = a=20 blueprint)
 
2.=20 7.1 Retrieve
    Is it possible to = retrieve=20 conferences based on serach criteria? and considering the result = set=20 could 
potentially run into the 1000s, should a = paging=20 mechanism be proposed in the SOAP = interface?
 
3.=20 Options Request
    The purpose of this = request is not=20 very clear, maybe the cmd is not named very well. In any=20 case,
the=20 usage of this cmd should be in the 'Examples' section also. So = basically=20 from what I gather, this cmd
is used=20 by the client to determine what namespaces the server understands and = their=20 associated blueprints?
It also states=20
 
 optionsRequest/optionsResponse:  = The=20 optionsRequest is used to
      ascertain = the=20 namespaces, conference reservations and = active
     =20 conferences supported by the server.  The optionsResponse=20 returns
      a list of the requested types = of=20 conference objects (e.g.,
      Blueprints,=20 Conference Reservations and/or Active=20 Confrences)
      supported by the specific=20 conference server.
I=20 dont understand why this cmd would be used to = return active=20 conferences also? Should that be a seperate=20 cmd?
 
Sean
 
 
    =
 
------_=_NextPart_001_01C8DAC0.0FEAF5C0-- --===============1324697684== 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 --===============1324697684==--