From xcon-bounces@ietf.org Wed Jan 03 19:19:10 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2GK1-0004Fw-5X; Wed, 03 Jan 2007 19:19:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H21YI-0002lE-EY
	for xcon@ietf.org; Wed, 03 Jan 2007 03:32:50 -0500
Received: from mail7.exchange.microsoft.com ([131.107.1.27]
	helo=mail.exchange.microsoft.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H21YC-0005Do-Rr
	for xcon@ietf.org; Wed, 03 Jan 2007 03:32:50 -0500
Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.211) by
	DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft
	SMTP Server (TLS) id 8.0.685.24; Wed, 3 Jan 2007 00:32:44 -0800
Received: from DF-COLLIE-MSG.exchange.corp.microsoft.com ([157.54.61.136]) by
	df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) with mapi;
	Wed, 3 Jan 2007 00:32:43 -0800
From: Srivatsa Srinivasan <srivats@exchange.microsoft.com>
To: "'Even, Roni'" <roni.even@polycom.co.il>, Mary Barnes
	<mary.barnes@nortel.com>, "xcon@ietf.org" <xcon@ietf.org>
Date: Wed, 3 Jan 2007 00:32:40 -0800
Subject: RE: [XCON] Feedback requested: draft-boulton-xcon-userid-00
Thread-Topic: [XCON] Feedback requested: draft-boulton-xcon-userid-00
Thread-Index: AccUpFkcft+tPN2WS5CCitqMyBURhACSfr5wBfTaxiA=
Message-ID: <CC36E1772A82C34DBE5F75E1CB549DDA36DA34135E@DF-COLLIE-MSG.exchange.corp.microsoft.com>
References: <E3F9D87C63E2774390FE67C924EC99BB0AB3DF48@zrc2hxm1.corp.nortel.com>
	<144ED8561CE90C41A3E5908EDECE315C041B2643@IsrExch01.israel.polycom.com>
In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C041B2643@IsrExch01.israel.polycom.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
X-Mailman-Approved-At: Wed, 03 Jan 2007 19:18:37 -0500
Cc: "cboulton@ubiquity.net" <cboulton@ubiquity.net>
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org


Sorry for the late comments. Agree with Roni on most of what was said below=
. I do not see why the mapping from user identifier to user id has to be st=
rictly (normatively) specified. The data model could be modified to include=
 the URIs that correspond to a specific user id. This could be easily accom=
plished by simply having a <conf-uris>-like container element (with the ass=
erted identities for that user) under the <user> element such that automata=
 can then use the mapping as necessary.

On the same topic, how are endpoints under the user identified? In the case=
 of SIP, the endpoint entity could be a simple numeric number (an endpoint =
id, unique within the conference) and the SIP URI corresponding to that cou=
ld be a GRUU. The data model could be modified to include this SIP URI corr=
esponding to the endpoint id. One use (albeit not great) of such an id is t=
o use it as the RTP CNAME in cases where the RTP SSRC cannot be used to ind=
icate active speaker. There could be other uses as well.

Srivatsa.

> -----Original Message-----
> From: Even, Roni [mailto:roni.even@polycom.co.il]
> Sent: Sunday, December 03, 2006 7:28 AM
> To: Mary Barnes; xcon@ietf.org
> Cc: cboulton@ubiquity.net
> Subject: RE: [XCON] Feedback requested: draft-boulton-xcon-userid-00
>
> Hi
> You had the following question in the draft
>
> 1. How much normative detail do we need to include in this document for
> the conference user identifier?
> RE: My view is minimum
>
>
> 2. Or are the deFrom xcon-bounces@ietf.org Wed Jan 03 19:19:10 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2GK1-0004Fw-5X; Wed, 03 Jan 2007 19:19:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H21YI-0002lE-EY
	for xcon@ietf.org; Wed, 03 Jan 2007 03:32:50 -0500
Received: from mail7.exchange.microsoft.com ([131.107.1.27]
	helo=mail.exchange.microsoft.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H21YC-0005Do-Rr
	for xcon@ietf.org; Wed, 03 Jan 2007 03:32:50 -0500
Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.211) by
	DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft
	SMTP Server (TLS) id 8.0.685.24; Wed, 3 Jan 2007 00:32:44 -0800
Received: from DF-COLLIE-MSG.exchange.corp.microsoft.com ([157.54.61.136]) by
	df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) with mapi;
	Wed, 3 Jan 2007 00:32:43 -0800
From: Srivatsa Srinivasan <srivats@exchange.microsoft.com>
To: "'Even, Roni'" <roni.even@polycom.co.il>, Mary Barnes
	<mary.barnes@nortel.com>, "xcon@ietf.org" <xcon@ietf.org>
Date: Wed, 3 Jan 2007 00:32:40 -0800
Subject: RE: [XCON] Feedback requested: draft-boulton-xcon-userid-00
Thread-Topic: [XCON] Feedback requested: draft-boulton-xcon-userid-00
Thread-Index: AccUpFkcft+tPN2WS5CCitqMyBURhACSfr5wBfTaxiA=
Message-ID: <CC36E1772A82C34DBE5F75E1CB549DDA36DA34135E@DF-COLLIE-MSG.exchange.corp.microsoft.com>
References: <E3F9D87C63E2774390FE67C924EC99BB0AB3DF48@zrc2hxm1.corp.nortel.com>
	<144ED8561CE90C41A3E5908EDECE315C041B2643@IsrExch01.israel.polycom.com>
In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C041B2643@IsrExch01.israel.polycom.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
X-Mailman-Approved-At: Wed, 03 Jan 2007 19:18:37 -0500
Cc: "cboulton@ubiquity.net" <cboulton@ubiquity.net>
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org


Sorry for the late comments. Agree with Roni on most of what was said below=
. I do not see why the mapping from user identifier to user id has to be st=
rictly (normatively) specified. The data model could be modified to include=
 the URIs that correspond to a specific user id. This could be easily accom=
plished by simply having a <conf-uris>-like container element (with the ass=
erted identities for that user) under the <user> element such that automata=
 can then use the mapping as necessary.

On the same topic, how are endpoints under the user identified? In the case=
 of SIP, the endpoint entity could be a simple numeric number (an endpoint =
id, unique within the conference) and the SIP URI corresponding to that cou=
ld be a GRUU. The data model could be modified to include this SIP URI corr=
esponding to the endpoint id. One use (albeit not great) of such an id is t=
o use it as the RTP CNAME in cases where the RTP SSRC cannot be used to ind=
icate active speaker. There could be other uses as well.

Srivatsa.

> -----Original Message-----
> From: Even, Roni [mailto:roni.even@polycom.co.il]
> Sent: Sunday, December 03, 2006 7:28 AM
> To: Mary Barnes; xcon@ietf.org
> Cc: cboulton@ubiquity.net
> Subject: RE: [XCON] Feedback requested: draft-boulton-xcon-userid-00
>
> Hi
> You had the following question in the draft
>
> 1. How much normative detail do we need to include in this document for
> the conference user identifier?
> RE: My view is minimum
>
>
> 2. Or are the details of the conference user identifier implementation
> specific and we just need to provide examples?
>
> RE: Just provide examples that will give some guidelines to how to
> specify users that are defined at conference reservation via XCON and
> how to give identity to unspecified users who dial the conference and
> join.
>
> 3. Does the definition require that the mapping to the user ids for
> other protocols be obvious (e.g., visibly derivable or would that be
> implementation specific?
>
> RE: Like question 2, give some guidelines.
>
> In general the user identifier is internal to the XCON document; also
> be
> aware that the user may be unknown when defining the conference, this
> is
> typical for participants who will dial to the conference, their
> identity
> will appear in the conference roster based on something like "asserted
> identity".
>
> BTW: What about specifying non-English display names, suggest to add
> display name field to the URI.
>
> Roni Even
>
> > -----Original Message-----
> > From: Mary Barnes [mailto:mary.barnes@nortel.com]
> > Sent: Thursday, November 30, 2006 7:24 PM
> > To: xcon@ietf.org
> > Cc: cboulton@ubiquity.net
> > Subject: [XCON] Feedback requested: draft-boulton-xcon-userid-00
> >
> > Per discussions at IETF-67, here's the reminder that we'd like
> feedback
> > on this draft:
> > http://www.ietf.org/internet-drafts/draft-boulton-xcon-userid-00.txt
> >
> > The conference user concept is introduced in the framework to
> identify
> > the entity participating in a conference and manipulating
> > conferencing system related properties.  This document defines a
> > Conference User Identifier and syntax for identifying a specific
> > conference user within a conferencing system.  The document also
> > describes the logical mapping of this conference user identifier to
> > protocol and signaling interface specific user identifiers.
> >
> > The questions are around how prescriptive we need to be in XCON
> > specifications as to the allocation, distribution and definition of
> this
> > identifier or would this all just be purely informational.   This
> > concept has been part of the framework from day one and it does seem
> to
> > be an important concept and something that should be part of the
> basic
> > data model, as well.
> >
> > Regards,
> > Mary
> >
> > _______________________________________________
> > XCON mailing list
> > XCON@ietf.org
> > https://www1.ietf.org/mailman/listinfo/xcon
> >
> >
> >
> >
> >
> >
> ***********************************************************************
> *
> **
> > **********
> > This footnote confirms that this email message has been scanned by
> > PineApp Mail-SeCure for the presence of malicious code, vandals &
> computer
> > viruses.
> >
> ***********************************************************************
> *
> **
> > **********
> >
> >
>
>
> _______________________________________________
> XCON mailing list
> XCON@ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon

From xcon-bounces@ietf.org Wed Jan 03 19:19:10 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2GJz-0004FV-W0; Wed, 03 Jan 2007 19:19:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H21Tw-0000hq-KV
	for xcon@ietf.org; Wed, 03 Jan 2007 03:28:20 -0500
Received: from mail1.exchange.microsoft.com ([131.107.1.17]
	helo=mail.exchange.microsoft.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H21Tu-0004Tf-9K
	for xcon@ietf.org; Wed, 03 Jan 2007 03:28:20 -0500
Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.211) by
	DF-GWY-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft
	SMTP Server (TLS) id 8.0.685.24; Wed, 3 Jan 2007 00:28:15 -0800
Received: from DF-COLLIE-MSG.exchange.corp.microsoft.com ([157.54.61.136]) by
	df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) with mapi;
	Wed, 3 Jan 2007 00:28tails of the conference user identifier implementation
> specific and we just need to provide examples?
>
> RE: Just provide examples that will give some guidelines to how to
> specify users that are defined at conference reservation via XCON and
> how to give identity to unspecified users who dial the conference and
> join.
>
> 3. Does the definition require that the mapping to the user ids for
> other protocols be obvious (e.g., visibly derivable or would that be
> implementation specific?
>
> RE: Like question 2, give some guidelines.
>
> In general the user identifier is internal to the XCON document; also
> be
> aware that the user may be unknown when defining the conference, this
> is
> typical for participants who will dial to the conference, their
> identity
> will appear in the conference roster based on something like "asserted
> identity".
>
> BTW: What about specifying non-English display names, suggest to add
> display name field to the URI.
>
> Roni Even
>
> > -----Original Message-----
> > From: Mary Barnes [mailto:mary.barnes@nortel.com]
> > Sent: Thursday, November 30, 2006 7:24 PM
> > To: xcon@ietf.org
> > Cc: cboulton@ubiquity.net
> > Subject: [XCON] Feedback requested: draft-boulton-xcon-userid-00
> >
> > Per discussions at IETF-67, here's the reminder that we'd like
> feedback
> > on this draft:
> > http://www.ietf.org/internet-drafts/draft-boulton-xcon-userid-00.txt
> >
> > The conference user concept is introduced in the framework to
> identify
> > the entity participating in a conference and manipulating
> > conferencing system related properties.  This document defines a
> > Conference User Identifier and syntax for identifying a specific
> > conference user within a conferencing system.  The document also
> > describes the logical mapping of this conference user identifier to
> > protocol and signaling interface specific user identifiers.
> >
> > The questions are around how prescriptive we need to be in XCON
> > specifications as to the allocation, distribution and definition of
> this
> > identifier or would this all just be purely informational.   This
> > concept has been part of the framework from day one and it does seem
> to
> > be an important concept and something that should be part of the
> basic
> > data model, as well.
> >
> > Regards,
> > Mary
> >
> > _______________________________________________
> > XCON mailing list
> > XCON@ietf.org
> > https://www1.ietf.org/mailman/listinfo/xcon
> >
> >
> >
> >
> >
> >
> ***********************************************************************
> *
> **
> > **********
> > This footnote confirms that this email message has been scanned by
> > PineApp Mail-SeCure for the presence of malicious code, vandals &
> computer
> > viruses.
> >
> ***********************************************************************
> *
> **
> > **********
> >
> >
>
>
> _______________________________________________
> XCON mailing list
> XCON@ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon

From xcon-bounces@ietf.org Wed Jan 03 19:19:10 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H2GJz-0004FV-W0; Wed, 03 Jan 2007 19:19:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H21Tw-0000hq-KV
	for xcon@ietf.org; Wed, 03 Jan 2007 03:28:20 -0500
Received: from mail1.exchange.microsoft.com ([131.107.1.17]
	helo=mail.exchange.microsoft.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H21Tu-0004Tf-9K
	for xcon@ietf.org; Wed, 03 Jan 2007 03:28:20 -0500
Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.211) by
	DF-GWY-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft
	SMTP Server (TLS) id 8.0.685.24; Wed, 3 Jan 2007 00:28:15 -0800
Received: from DF-COLLIE-MSG.exchange.corp.microsoft.com ([157.54.61.136]) by
	df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) with mapi;
	Wed, 3 Jan 2007 00:28:15 -0800
From: Srivatsa Srinivasan <srivats@exchange.microsoft.com>
To: 'Mary Barnes' <mary.barnes@nortel.com>, "xcon@ietf.org" <xcon@ietf.org>
Date: Wed, 3 Jan 2007 00:28:11 -0800
Subject: RE: [XCON] Feedback requested: draft-boulton-xcon-uri-00
Thread-Topic: [XCON] Feedback requested: draft-boulton-xcon-uri-00
Thread-Index: AccUpGVuaXSlIFacQki9/VbtYga4OQaFz0sg
Message-ID: <CC36E1772A82C34DBE5F75E1CB549DDA36DA34135B@DF-COLLIE-MSG.exchange.corp.microsoft.com>
References: <E3F9D87C63E2774390FE67C924EC99BB0AB3DF49@zrc2hxm1.corp.nortel.com>
In-Reply-To: <E3F9D87C63E2774390FE67C924EC99BB0AB3DF49@zrc2hxm1.corp.nortel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
X-Mailman-Approved-At: Wed, 03 Jan 2007 19:18:36 -0500
Cc: "cboulton@ubiquity.net" <cboulton@ubiquity.net>
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

Hi Mary and Chris,

Sorry for the late comments. Overall, the idea of having a separate identif=
ier to identify the conference object resource sounds useful. Was there a r=
eason for using a new scheme based URI instead of a simple unique identifie=
r? Some text in the introduction to make the motivation clear would help. A=
lso, do you foresee the XCON URI to be a routable entity in the future? Per=
haps some normative text there regarding its use would be beneficial?

More comments follow.

>From Section 3
  " Editors Note: Part of the extension to the Conference Package for
   XCON? "

[SS] The data model and conference package for XCON should have text descri=
bing where an XCON URI may appear in the document. It's usage should howeve=
r be specified in this document, the framework and the conference control p=
rotocol if I understand correctly.

>From Section 3.1
"   The left hand side of the URI (to the left of the '@') represents the
   unique token.  This token can be used by any protocol wishing to gain
   access to functionality associated with a specific conference object.
   For example, when used to construct a SIP INVITE request, the token
   would be used to populate the 'user' part of the SIP URI - as defined
   in RFC 3261[2].  The right hand side of the URI, as with any URI,
   provides domain level information ('example.com' in previous
   example).  So continuing the previous example, the SIP URI domain
   part would be equal to this domain information."

[SS] Is the above text implying that, given an XCON URI, a client/implement=
ation can construct an equivalent SIP URI by just parsing out sections from=
 the XCON URI and forming the SIP URI? I think giving normative detail here=
 with respect to the mapping is quite unnecessary and may in fact cause int=
er-op issues (if implemented incorrectly). Inclusion of these terms should =
not prevent an implementation from using SIP URI's instead of XCON URI's al=
l over the place (in the data model) without breaking normative behavior, c=
orrect?

Srivatsa.


> -----Original Message-----
> From: Mary Barnes [mailto:mary.barnes@nortel.com]
> Sent: Thursday, November 30, 2006 9:25 AM
> To: xcon@ietf.org
> Cc: cboulton@ubiquity.net
> Subject: [XCON] Feedback requested: draft-boulton-xcon-uri-00
>
> Per discussions at IETF-67, here's the reminder that we'd like feedback
> on this draft:
> http://www.ietf.org/internet-drafts/draft-boulton-xcon-uri-00.txt
>
> This document defines a URI scheme and syntax for the conference object
> identifier, as defined in "A Framework and Data Model for Centra:15 -0800
From: Srivatsa Srinivasan <srivats@exchange.microsoft.com>
To: 'Mary Barnes' <mary.barnes@nortel.com>, "xcon@ietf.org" <xcon@ietf.org>
Date: Wed, 3 Jan 2007 00:28:11 -0800
Subject: RE: [XCON] Feedback requested: draft-boulton-xcon-uri-00
Thread-Topic: [XCON] Feedback requested: draft-boulton-xcon-uri-00
Thread-Index: AccUpGVuaXSlIFacQki9/VbtYga4OQaFz0sg
Message-ID: <CC36E1772A82C34DBE5F75E1CB549DDA36DA34135B@DF-COLLIE-MSG.exchange.corp.microsoft.com>
References: <E3F9D87C63E2774390FE67C924EC99BB0AB3DF49@zrc2hxm1.corp.nortel.com>
In-Reply-To: <E3F9D87C63E2774390FE67C924EC99BB0AB3DF49@zrc2hxm1.corp.nortel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
X-Mailman-Approved-At: Wed, 03 Jan 2007 19:18:36 -0500
Cc: "cboulton@ubiquity.net" <cboulton@ubiquity.net>
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

Hi Mary and Chris,

Sorry for the late comments. Overall, the idea of having a separate identif=
ier to identify the conference object resource sounds useful. Was there a r=
eason for using a new scheme based URI instead of a simple unique identifie=
r? Some text in the introduction to make the motivation clear would help. A=
lso, do you foresee the XCON URI to be a routable entity in the future? Per=
haps some normative text there regarding its use would be beneficial?

More comments follow.

>From Section 3
  " Editors Note: Part of the extension to the Conference Package for
   XCON? "

[SS] The data model and conference package for XCON should have text descri=
bing where an XCON URI may appear in the document. It's usage should howeve=
r be specified in this document, the framework and the conference control p=
rotocol if I understand correctly.

>From Section 3.1
"   The left hand side of the URI (to the left of the '@') represents the
   unique token.  This token can be used by any protocol wishing to gain
   access to functionality associated with a specific conference object.
   For example, when used to construct a SIP INVITE request, the token
   would be used to populate the 'user' part of the SIP URI - as defined
   in RFC 3261[2].  The right hand side of the URI, as with any URI,
   provides domain level information ('example.com' in previous
   example).  So continuing the previous example, the SIP URI domain
   part would be equal to this domain information."

[SS] Is the above text implying that, given an XCON URI, a client/implement=
ation can construct an equivalent SIP URI by just parsing out sections from=
 the XCON URI and forming the SIP URI? I think giving normative detail here=
 with respect to the mapping is quite unnecessary and may in fact cause int=
er-op issues (if implemented incorrectly). Inclusion of these terms should =
not prevent an implementation from using SIP URI's instead of XCON URI's al=
l over the place (in the data model) without breaking normative behavior, c=
orrect?

Srivatsa.


> -----Original Message-----
> From: Mary Barnes [mailto:mary.barnes@nortel.com]
> Sent: Thursday, November 30, 2006 9:25 AM
> To: xcon@ietf.org
> Cc: cboulton@ubiquity.net
> Subject: [XCON] Feedback requested: draft-boulton-xcon-uri-00
>
> Per discussions at IETF-67, here's the reminder that we'd like feedback
> on this draft:
> http://www.ietf.org/internet-drafts/draft-boulton-xcon-uri-00.txt
>
> This document defines a URI scheme and syntax for the conference object
> identifier, as defined in "A Framework and Data Model for Centralized
> Conferencing".
>
> This identifier has been a fundamental concept in the XCON framework
> from the beginning and seems quite necessary. I think this draft is
> fairly complete and the identifier itself is already part of the data
> model, as pointed out by Oscar.
>
> So, the questions would be how much more detail is necessary in this
> document and can it be accepted as a WG document?
>
> Regards,
> Mary
>
> _______________________________________________
> XCON mailing list
> XCON@ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon





lized
> Conferencing".
>
> This identifier has been a fundamental concept in the XCON framework
> from the beginning and seems quite necessary. I think this draft is
> fairly complete and the identifier itself is already part of the data
> model, as pointed out by Oscar.
>
> So, the questions would be how much more detail is necessary in this
> document and can it be accepted as a WG document?
>
> Regards,
> Mary
>
> _______________________________________________
> XCON mailing list
> XCON@ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon





From xcon-bounces@ietf.org Fri Jan 12 07:24:46 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H5LSc-0002ii-Be; Fri, 12 Jan 2007 07:24:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H5LSa-0002eH-Em
	for xcon@ietf.org; Fri, 12 Jan 2007 07:24:40 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5LSV-0002AX-Bo
	for xcon@ietf.org; Fri, 12 Jan 2007 07:24:40 -0500
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9FF304E1; 
	Fri, 12 Jan 2007 13:24:30 +0100 (CET)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 12 Jan 2007 13:24:30 +0100
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 12 Jan 2007 13:24:30 +0100
Received: from [131.160.36.45] (EH3I2003TGFCPET-131160036045.lmf.ericsson.se
	[131.160.36.45])
	by mail.lmf.ericsson.se (Postfix) with ESMTP id 149612358;
	Fri, 12 Jan 2007 14:24:30 +0200 (EET)
Message-ID: <45A77DFD.4020108@ericsson.com>
Date: Fri, 12 Jan 2007 14:24:29 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: XCON <xcon@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Jan 2007 12:24:30.0186 (UTC)
	FILETIME=[9BBCB4A0:01C73644]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: Adam Roach <adam@nostrum.com>, Alan Johnston <alan@sipstation.com>
Subject: [XCON] BFCP connection draft
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

Folks,

I have put together a new revision of the BFCP connection draft that 
addresses all the comments received during its WGLC. In particular, this 
revision does not define a BFCP-based digest mechanism any longer. 
Instead, it uses PSK-TLS to perform client authentication.

Until it is available on the archives, you can fetch it from:

http://users.piuha.net/gonzalo/temp/draft-ietf-xcon-bfcp-connection-03.txt

If possible, I would like to ask the chairs to give the WG some time to 
have a look at this revision before requesting its publication so that 
folks have a chance to review the changes introduced in its WGLC.

Cheers,

Gonzalo

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Fri Jan 12 18:50:25 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H5WA9-00022C-5z; Fri, 12 Jan 2007 18:50:21 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H5W9q-0001zN-JT; Fri, 12 Jan 2007 18:50:02 -0500
Received: from ns0.neustar.com ([156.154.16.158])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1H5W9p-0003lW-Tj; Fri, 12 Jan 2007 18:50:02 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id D7E8032992;
	Fri, 12 Jan 2007 23:50:01 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1H5W9p-0001Mj-OV; Fri, 12 Jan 2007 18:50:01 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1H5W9p-0001Mj-OV@stiedprstage1.ietf.org>
Date: Fri, 12 Jan 2007 18:50:01 -0500
X-Spam-Score: -2.5 (--)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: xcon@ietf.org
Subject: [XCON] I-D ACTION:draft-ietf-xcon-bfcp-connection-03.txt 
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
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		: Connection Establishment in the Binary Floor Control Protocol (BFCP)
	Author(s)	: G. Camarillo
	Filename	: draft-ietf-xcon-bfcp-connection-03.txt
	Pages		: 10
	Date		: 2007-1-12
	
This document specifies how a Binary Floor Control Protocol (BFCP)
   client establishes a connection to a BFCP floor control server
   outside the context of an offer/answer exchange.  Client and server
   authentication are based on Transport Layer Security (TLS).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-xcon-bfcp-connection-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-xcon-bfcp-connection-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-xcon-bfcp-connection-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-1-12151627.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-xcon-bfcp-connection-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-xcon-bfcp-connection-03.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-1-12151627.I-D@ietf.org>


--OtherAccess--

--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://www1.ietf.org/mailman/listinfo/xcon

--NextPart--





From xcon-bounces@ietf.org Fri Jan 12 23:29:23 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H5aW0-0005vR-Fd; Fri, 12 Jan 2007 23:29:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H5aVu-0005tc-LS; Fri, 12 Jan 2007 23:29:06 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1H5aVs-0002bo-Bi; Fri, 12 Jan 2007 23:29:06 -0500
Received: from sj-dkim-8.cisco.com ([171.68.10.93])
	by sj-iport-5.cisco.com with ESMTP; 12 Jan 2007 20:29:03 -0800
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138])
	by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l0D4T2Ia012932; 
	Fri, 12 Jan 2007 20:29:02 -0800
Received: from [192.168.1.9] (sjc-vpn7-387.cisco.com [10.21.145.131])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0D4T2nF020709;
	Fri, 12 Jan 2007 20:29:02 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <F488C7FA-A0AB-44D2-A995-1A44AE183FF6@cisco.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: rai@ietf.org, avt@ietf.org, ECRIT <ecrit@ietf.org>, enum@ietf.org,
	mmusic@ietf.org, sigtran@ietf.org, simple@ietf.org, geopriv@ietf.org,
	ieprep@ietf.org, SIP <sip@ietf.org>, sipping@ietf.org,
	speechsc@ietf.org, speermint@ietf.org, xcon@ietf.org,
	RAI Chairs <rai-chairs@ietf.org>, RAI Discuss <rai-discuss@ietf.org>
From: Cullen Jennings <fluffy@cisco.com>
Date: Fri, 12 Jan 2007 20:28:52 -0800
X-Mailer: Apple Mail (2.752.3)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=484; t=1168662542;
	x=1169526542; c=relaxed/relaxed; s=sjdkim8002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=fluffy@cisco.com;
	z=From:=20Cullen=20Jennings=20<fluffy@cisco.com>
	|Subject:=20New=20RAI=20mailing=20list=20formed |Sender:=20;
	bh=oy9hMDTAd3CLwx2VjaSlGDIiUGc4zeKQTh4WxAq1xfU=;
	b=nzE6bx99AfmpN9XXdKKYeMzdSrPYLU0XznGtkrDuKY24XeITEuEnaaVR9hz7VFmVb9njtbTr
	5VVkwN8evTl13ZapqifDuRHeokxVdDOoFkvhoDOAduovqFL7TFD5fRZC;
Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass (
	sig from cisco.com/sjdkim8002 verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: 
Subject: [XCON] New RAI mailing list formed
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org


Please don't reply to this message so you don't cross post to all the  
groups.

A new mailing list for announcement and discussion of general topics  
of interest to RAI Area has been created. The list is rai@ietf.org

You can subscribe at:
https://www1.ietf.org/mailman/listinfo/rai
Or by sending email with a body containing "subscribe" to rai- 
request@ietf.org

Please do subscribe to it so you can find announcements for things  
like RAI BOFs.

Thanks,
Cullen & Jon


_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Thu Jan 18 12:00:13 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7acR-0005gn-Te; Thu, 18 Jan 2007 12:00:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7acP-0005eF-PU
	for xcon@ietf.org; Thu, 18 Jan 2007 12:00:05 -0500
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7acN-0006tv-90
	for xcon@ietf.org; Thu, 18 Jan 2007 12:00:05 -0500
Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com
	[47.103.123.72])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l0IGxie28314; Thu, 18 Jan 2007 11:59:44 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [XCON] WGLC: draft-ietf-xcon-framework-06
Date: Thu, 18 Jan 2007 10:59:26 -0600
Message-ID: <E3F9D87C63E2774390FE67C924EC99BB0AB3E021@zrc2hxm1.corp.nortel.com>
In-Reply-To: <6900257941B31D4A954C71DEF805B9A20BBC5D35@nj7460avexu2.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [XCON] WGLC: draft-ietf-xcon-framework-06
Thread-Index: AccYtD0vcEduyTUHTgm305MeD1+TqwQZTXAgAGAVOOAADdyFUAQUCKag
From: "Mary Barnes" <mary.barnes@nortel.com>
To: "Braudes, Robert \(Bob\)" <braudes@avaya.com>,
	"Adam Roach" <adam@nostrum.com>, "XCON-IETF" <xcon@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1
Cc: Alan Johnston <alan@sipstation.com>
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

I'm in the process of completing the updates (these were the only
comments received during the WGLC) and wanted to make sure that no one
had an issue with Bob's suggestion below to allow a single user to have
multiple Conference User Identifiers (e.g., for multiple roles within a
conferencing system).=20

I plan on completing the updates and submitting the updated version by
the end of this week. This version (-07) should be ready for forwarding
to the IESG.

Mary

-----Original Message-----
From: Braudes, Robert (Bob) [mailto:braudes@avaya.com]=20
Sent: Sunday, December 31, 2006 3:53 PM
To: Barnes, Mary (RICH2:AR00); Adam Roach; XCON-IETF
Cc: Alan Johnston
Subject: RE: [XCON] WGLC: draft-ietf-xcon-framework-06


Hi Mary,=20

	Thanks for the detailed response.  Please see comments below
[BB].

Bob

-----Original Message-----
From: Mary Barnes [mailto:mary.barnes@nortel.com]=20
Sent: Thursday, December 28, 2006 12:01 PM
To: Braudes, Robert (Bob); Adam Roach; XCON-IETF
Cc: Mary Barnes; Alan Johnston
Subject: RE: [XCON] WGLC: draft-ietf-xcon-framework-06

Bob,

Thanks for your comments and reviewing the document - responses are
embedded below [MB].

Mary


-----Original Message-----
From: Braudes, Robert (Bob) [mailto:braudes@avaya.com]
Sent: Tuesday, December 26, 2006 1:01 PM
To: Adam Roach; XCON-IETF
Cc: Mary Barnes; Alan Johnston
Subject: RE: [XCON] WGLC: draft-ietf-xcon-framework-06


I have two small nits and a few questions and comments.  The first nit
is that I believe that in Section 8.4, Floor Control, in the last
sentence in the fifth paragraph, "conference identifier" is supposed to
be "conference user identifier".

[MB] Yes, I will fix that.=20

A related question, which perhaps should be directed to
draft-boutlon-xcon-userid-00, is whether conference user IDs are unique
across a conferencing system or just within a given conference (and
probably sidebars off of that conference).  Having the id have a
conference scope will allow a user to have different roles for different
conferences, distinguished by his/her conference user ID.  I can see
arguments to implement this either way, and suggest that we leave this
up to the policy of the conferencing system. =20

[MB] From the text in section 6.3 (and the boulton draft), it seems
clear that the conference user identifier is specified to be unique
across a conferencing system. I think that's necessary to account for
users that aren't participants in an active conference, but that might
still be able to manipulate a conference.  We didn't, however, include a
definition upfront (in section 4) for the Conference User Identifier. =20
I would propose we add a definition like the following to section 4:
NEW:
Conference User Identifer:  A unique identifer for a user within the
scope of a
   conferencing system. =20
[/MB]

[BB] After giving it additional thought, I didn't word my concern about
the Conference User Identifier appropriately.  I agree that each ID
needs
to uniquely identify a single User.  What I would like to see is the
potential for that User to have multiple identifiers in the Conferencing
System, each (potentially) associated with a different set of
attributes. =20
This does not have any impact on what you have written above, but you
may=20
want to add a statement like=20

"A User MAY have multiple Conference User Identifiers defined within a
Conferencing System."
[/BB]

One question is in relation to section 9.4, Sidebar Manipulations.  In
this section, it is mentioned  that no members from outside the parent
conference instance can join a sidebar.  Given the text in Section 9.4.1
that discusses whether or not "Bob" is a new user of this conferencing
system, and the example in 9.4.2 of an External Sidebar, I am assuming
that the statement of only allowing members of the parent conference is
a local policy decision, and if so then this could be clarified in the
draft.
[MB] Yes, the last sentence in the second paragraph of section 9.4 gives
as an example a policy that restricts the membership of the sidebar to
members of the parent conference and this is provided as an example of
an "internal" sidebar in section 9.4.1.  So, the text in section 9.4.1
(the last two sentences in the second to last paragraph) should be
corrected to reflect that no members from outside the parent conference
can join an internal sidebar.  I'd propose the following change:
OLD:
  The conferencing system must also validate the updated information in
the reservation,=20
  ensuring whether members like "Bob" are already a user of this
conferencing system=20
  or whether he is a new user. If "Bob" is a new user for this
conferencing system, a=20
  conference user identifier is created for Bob.  Based upon the
addressing information=20
  provided for "Bob" by "Alice", the call signaling to add "Bob" to the
conference is=20
  instigated through the Focus.  =20
NEW:=20
  The conferencing system must also validate the updated information in
the reservation,=20
  ensuring that a member like "Bob" is already a user of this
conferencing system.=20
[/MB]

[BB] Thanks.
[/BB]

Another minor point is that in the examples that include the
notification service, the person that initiated the action that caused
the notification is not listed as a recipient of the notification.  In
practice, the event is often sent to all registered listeners, including
the listener who triggered the event.
[MB] Yes, this is an oversight and it should at least be mentioned that
the initiator could also be notified.  I propose to change the following
statement to account for this (this is (similar to) the last sentence in
the last paragraph in sections 9.4.1, 9.4.2 and 9.7):
OLD:
  Depending upon the policies, the participants in the sidebar (i.e.,
"Bob") may be notified=20
  of his addition to the sidebar via the conference notification
service.=20

NEW:
  Depending upon the policies, the initiator of the request (i.e.,
"Alice") and the=20
  participants in the sidebar (i.e., "Bob") may be notified=20
  of his addition to the sidebar via the conference notification
service.=20
[/MB]

[BB] Thanks again.
[/BB]

In Section 9.5, it may be beneficial to add a note that when Analyst A1
asks his question, other members of the main conference will not hear
the question, unless I am missing something.
[MB] I think the main conference would hear the question. However, I
think the sentence in the paragraph just prior to Figure 14 might have
been intended to say that all participants in the main conference
receive the audio from the sidebar, as well as the main conference, so
I'd propose the following change:
OLD:
  All participants in the sidebar conference receive audio from the main
conference.

NEW:=20
  All participants in the main conference receive audio from the sidebar
conference, as well as=20
  audio provided by the panelists in the main conference.=20
[/MB]

[BB] I agree that this will work given the constraints of the usage of
this=20
sidebar, where only the Analyst asking the question has the floor.
[/BB]

The second nit is that in the fourth paragraph of Section 9.9 it should
say "coaching".
[MB] Yes, I'll fix that.=20

I apologize in advance if any of these issues have been previously
discussed.
[MB] No, these are all new points and worth discussing as alot of this
is in newer sections and text which had not been reviewed during past
detailed reviews.
[/MB]

Bob

-----Original Message-----
From: Adam Roach [mailto:adam@nostrum.com]=20
Sent: Tuesday, December 05, 2006 4:26 PM
To: XCON-IETF
Cc: Mary Barnes; Alan Johnston
Subject: [XCON] WGLC: draft-ietf-xcon-framework-06

The working group chairs are announcing a two-week Working Group Last
Call for the XCON Framework Document (draft-ietf-xcon-framework-06),
starting today. It will continue until Wednesday, December 20th.

http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-06.txt

Please send any comments to the XCON mailing list.

Thanks!

/a


_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon


_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Thu Jan 18 14:31:05 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H7cyT-0000iV-BR; Thu, 18 Jan 2007 14:31:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H7cyR-0000hD-N5
	for xcon@ietf.org; Thu, 18 Jan 2007 14:30:59 -0500
Received: from [198.152.12.103] (helo=nj300815-ier2.net.avaya.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7cyP-0007fX-L9
	for xcon@ietf.org; Thu, 18 Jan 2007 14:30:59 -0500
Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com
	[198.152.6.52])
	by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP
	id l0IJUuss021401
	for <xcon@ietf.org>; Thu, 18 Jan 2007 14:30:56 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 18 Jan 2007 14:30:56 -0500
Message-ID: <6900257941B31D4A954C71DEF805B9A20BD9871D@nj7460avexu2.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Review of draft-ietf-xcon-framework-06
Thread-Index: Acc7NyyOvFXQUkUbQwmr8oR2cMvMFw==
From: "Sperounes, Gregory \(Gregory\)" <sperounes@avaya.com>
To: <xcon@ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
X-Spam-Score: 0.1 (/)
X-Scan-Signature: da41e01217ab11ad82db577473e913ae
Subject: [XCON] Review of draft-ietf-xcon-framework-06
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1617357095=="
Errors-To: xcon-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1617357095==
content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C73B37.2D00638E"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C73B37.2D00638E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Review of draft-ietf-xcon-framework-06:

------
In 9.4.1=20

"Alice" and "Bob" would remain on the roster of the main conference such
that the other participants would be unaware of the sidebar.
-------

-------
The statement above should probably state:

"Alice" and "Bob" would remain on the roster of the main conference such
that other participants could be aware of their participation in the
main conference while an internal-sidebar conference (or whisper) is
occurring.
-------

The state of internal/external sidebar should be used to denote
main-conference audio mixing while in a sidebar conference.

The concern at the heart of this comment is for clarity of state in the
framework.

An application can expose the whisper state, or show it as a kind of
muted state, or hide the whisper state entirely, but the framework
should expose a very clear state of all participants and conferences and
sidebars, without inferring or hiding state.

I completely agree with the concept of remaining on the meeting roster,
because the participation in the meeting, is separate from being in
a room or sidebar.=20

Can the notifications that a client receives, be
managed/filtered/interpreted, by the focus based on the role of the
client after authentication and authorization?

Some means of  interpreting state changes before notifying particular
clients should exist, so long as the heart of the framework provides a
clear indication of all states.  =20

-------
In the next section 9.4.2, there is a suggestion that the
external-sidebar state be denoted by a hold-state indication.

"Alice" initiates the sidebar by sending a request to the conferencing
system to create a conference reservation based upon the active
conference object.  "Alice", "Bob" and "Ethel" would remain on the
roster of the main conference in a hold state."
-------

The same concern and comment applies:

The framework should be able to clearly expose the external-sidebar
state and allow the application to interpret and present that as an
external-sidebar state, a hold-state, a locked sidebar state, or some
other sidebar state. If there is some means by which the actual state
can be converted or interpreted for specific clients that should be
identified as separate from the actual framework behavior and state
information.=20

The heart of the framework should not be masking, or inferring state,
when the actual state is much clearer and provides a more powerful means
of controlling, and negotiating end user perceptions and options.

In the two examples of internal and external sidebars, the state shown
in the roster, may collide in undesirable ways with self-muted and
chair-muted, or self-held and chair-held states, when participants are
actually in sidebars, or when they return form sidebars, or when more
superior applications would benefit from the clarity of sidebar state
information for security purposes.

----------
Along this line of reasoning:

The framework should be able to clearly expose the cause of appearing to
be muted in a conference=20
as a result of being a self-muted, a chair-muted (or silenced) , an
operator-muted, conference-feature-muted (lecture, mute-all, Q&A), or
menu-muted (for DTMF commands, or IVR routines).=20

All of these mutes for a participant overlap and become important
information for superb application experiences.
The end user may only see isMuted as a light on their screen, the
framework should be able to individually
manipulate the various overlapping and intermingling causes for a mute
state.

I may be interpreting the framework draft examples too precisely.
I thought it would be worth mentioning in case the boundary between
framework state and end-user experience are being blurred.

Greg Sperounes
Conferencing API Team, GCS/UCD
Avaya Inc
+1-978-677-5096

Included: Referenced excerpts in context

9.4.1.  Internal Sidebar

   Figure 12 provides an example of one client "Alice" involved in
   active conference with "Bob" and "Carol".  "Alice" wants to create a
   sidebar to have a side discussion with "Bob" while still viewing the
   video associated with the main conference.  Alternatively, the audio
   from the main conference could be maintained at a reduced volume.
   "Alice" initiates the sidebar by sending a request to the
   conferencing system to create a conference reservation based upon the
   active conference object.  "Alice" and "Bob" would remain on the
   roster of the main conference such that the other participants would
   be unaware of the sidebar.


9.4.2.  External Sidebar

   Figure 13 provides an example of one client "Alice" involved in an
   active conference with "Bob", "Carol", "David" and "Ethel".  "Alice"
   gets an important text message via a whisper from "Bob" that a
   critical customer needs to talk to "Alice", "Bob" and "Ethel".
   "Alice" creates a sidebar to have a side discussion with the customer
   "Fred" including the participants in the current conference with the
   exception of "Carol" and "David", who remain in the active
   conference.  "Alice" initiates the sidebar by sending a request to
   the conferencing system to create a conference reservation based upon
   the active conference object.  "Alice", "Bob" and "Ethel" would
   remain on the roster of the main conference in a hold state.  Whether
   or not the hold state of these participants is visible to other
   participants depends upon the individual and local policy.



------_=_NextPart_001_01C73B37.2D00638E
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.6618.4">
<TITLE>Review of draft-ietf-xcon-framework-06</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">Review of =
draft-ietf-xcon-framework-06:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">------</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">In 9.4.1 </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;Alice&quot; and &quot;Bob&quot; =
would remain on the roster of the main conference such that the other =
participants would be unaware of the sidebar.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-------</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-------</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">The statement above should probably =
state:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;Alice&quot; and &quot;Bob&quot; =
would remain on the roster of the main conference such that other =
participants could be aware of their participation in the main =
conference while an internal-sidebar conference (or whisper) is =
occurring.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-------</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The state of internal/external sidebar =
should be used to denote main-conference audio mixing while in a sidebar =
conference.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The concern at the heart of this =
comment is for clarity of state in the framework.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">An application can expose the whisper =
state, or show it as a kind of muted state, or hide the whisper state =
entirely, but the framework should expose a very clear state of all =
participants and conferences and sidebars, without inferring or hiding =
state.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I completely agree with the concept of =
remaining on the meeting roster, because the participation in the =
meeting, is separate from being in</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">a room or sidebar. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Can the notifications that a client =
receives, be managed/filtered/interpreted, by the focus based on the =
role of the client after authentication and authorization?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Some means of&nbsp; interpreting state =
changes before notifying particular clients should exist, so long as the =
heart of the framework provides a clear indication of all =
states.&nbsp;&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-------</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">In the next section 9.4.2, there is a =
suggestion that the external-sidebar state be denoted by a hold-state =
indication.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;Alice&quot; initiates the sidebar =
by sending a request to the conferencing system to create a conference =
reservation based upon the active conference object.&nbsp; =
&quot;Alice&quot;, &quot;Bob&quot; and &quot;Ethel&quot; would remain on =
the roster of the main conference in a hold state.&quot;</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-------</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The same concern and comment =
applies:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The framework should be able to clearly =
expose the external-sidebar state and allow the application to interpret =
and present that as an external-sidebar state, a hold-state, a locked =
sidebar state, or some other sidebar state. If there is some means by =
which the actual state can be converted or interpreted for specific =
clients that should be identified as separate from the actual framework =
behavior and state information. </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The heart of the framework should not =
be masking, or inferring state, when the actual state is much clearer =
and provides a more powerful means of controlling, and negotiating end =
user perceptions and options.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In the two examples of internal and =
external sidebars, the state shown in the roster, may collide in =
undesirable ways with self-muted and chair-muted, or self-held and =
chair-held states, when participants are actually in sidebars, or when =
they return form sidebars, or when more superior applications would =
benefit from the clarity of sidebar state information for security =
purposes.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">----------</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Along this line of reasoning:</FONT>
<BR>

<BR><FONT SIZE=3D2 FACE=3D"Arial">The framework should be able to =
clearly expose the cause of appearing to be muted in a conference =
</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">as a result of being a self-muted, a =
chair-muted (or silenced) , an operator-muted, conference-feature-muted =
(lecture, mute-all, Q&amp;A), or menu-muted (for DTMF commands, or IVR =
routines). </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">All of these mutes for a participant =
overlap and become important information for superb application =
experiences.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">The end user may only see isMuted as a =
light on their screen, the framework should be able to =
individually</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">manipulate the various overlapping and =
intermingling causes for a mute state.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I may be interpreting the framework =
draft examples too precisely.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">I thought it would be worth mentioning =
in case the boundary between framework state and end-user experience are =
being blurred.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Greg Sperounes</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Conferencing API Team, GCS/UCD</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Avaya Inc</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&#43;1-978-677-5096</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Included: Referenced excerpts in =
context</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">9.4.1.&nbsp; Internal Sidebar</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; Figure 12 provides an =
example of one client &quot;Alice&quot; involved in</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; active conference with =
&quot;Bob&quot; and &quot;Carol&quot;.&nbsp; &quot;Alice&quot; wants to =
create a</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; sidebar to have a side =
discussion with &quot;Bob&quot; while still viewing the</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; video associated with the =
main conference.&nbsp; Alternatively, the audio</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; from the main conference =
could be maintained at a reduced volume.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; &quot;Alice&quot; =
initiates the sidebar by sending a request to the</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; conferencing system to =
create a conference reservation based upon the</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; active conference =
object.&nbsp; &quot;Alice&quot; and &quot;Bob&quot; would remain on =
the</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; roster of the main =
conference such that the other participants would</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; be unaware of the =
sidebar.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">9.4.2.&nbsp; External Sidebar</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; Figure 13 provides an =
example of one client &quot;Alice&quot; involved in an</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; active conference with =
&quot;Bob&quot;, &quot;Carol&quot;, &quot;David&quot; and =
&quot;Ethel&quot;.&nbsp; &quot;Alice&quot;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; gets an important text =
message via a whisper from &quot;Bob&quot; that a</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; critical customer needs =
to talk to &quot;Alice&quot;, &quot;Bob&quot; and =
&quot;Ethel&quot;.</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; &quot;Alice&quot; creates =
a sidebar to have a side discussion with the customer</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; &quot;Fred&quot; =
including the participants in the current conference with the</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; exception of =
&quot;Carol&quot; and &quot;David&quot;, who remain in the active</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; conference.&nbsp; =
&quot;Alice&quot; initiates the sidebar by sending a request to</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; the conferencing system =
to create a conference reservation based upon</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; the active conference =
object.&nbsp; &quot;Alice&quot;, &quot;Bob&quot; and &quot;Ethel&quot; =
would</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; remain on the roster of =
the main conference in a hold state.&nbsp; Whether</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; or not the hold state of =
these participants is visible to other</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; participants depends upon =
the individual and local policy.</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C73B37.2D00638E--


--===============1617357095==
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://www1.ietf.org/mailman/listinfo/xcon

--===============1617357095==--




From xcon-bounces@ietf.org Fri Jan 19 16:21:02 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H81AT-0000hB-MC; Fri, 19 Jan 2007 16:21:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H81AT-0000h5-5G
	for xcon@ietf.org; Fri, 19 Jan 2007 16:21:01 -0500
Received: from wx-out-0506.google.com ([66.249.82.230])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H81AR-00058B-Cr
	for xcon@ietf.org; Fri, 19 Jan 2007 16:21:01 -0500
Received: by wx-out-0506.google.com with SMTP id h31so621707wxd
	for <xcon@ietf.org>; Fri, 19 Jan 2007 13:20:58 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=bTOnr6Up1QdU03nmEZ7QSYT/Ja7bWJhCRmqNW66F2F8lL9iviVMEFqnvJIJcEfCJNriBz+Sls6wU73xM9A0FKSxFScj3OtiHLyxBGv8emLelMjMD926oVAReRJ+Pg/SKlVaPsOA+iz0tTsywqdOsAAuxulaTCTbveRlC+Cv3P6E=
Received: by 10.70.91.11 with SMTP id o11mr4688365wxb.1169241658365;
	Fri, 19 Jan 2007 13:20:58 -0800 (PST)
Received: by 10.70.123.17 with HTTP; Fri, 19 Jan 2007 13:20:58 -0800 (PST)
Message-ID: <11e0ee130701191320o7d1485catef1206a9108a8cf4@mail.gmail.com>
Date: Fri, 19 Jan 2007 15:20:58 -0600
From: "Mary Barnes" <mary.h.barnes@gmail.com>
To: sperounes@avaya.com
In-Reply-To: <11e0ee130701191254t480d7883od97b5be617bbca73@mail.gmail.com>
MIME-Version: 1.0
References: <11e0ee130701191254t480d7883od97b5be617bbca73@mail.gmail.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4f585e1bcd209294c6b9386034cecfc6
Cc: xcon@ietf.org
Subject: [XCON] Re: Review of draft-ietf-xcon-framework-06
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0000289294=="
Errors-To: xcon-bounces@ietf.org

--===============0000289294==
Content-Type: multipart/alternative; 
	boundary="----=_Part_114809_18888160.1169241658322"

------=_Part_114809_18888160.1169241658322
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Gregory,

Thanks for your comments.  I'm replying from my gmail account as my usual
email server is down right now.  My responses are below [MB].

Just to give folks some time to comment, I'll wait till noon CST on Monday,
January 22nd to submit the updated document.

Mary.


On 1/18/07, "Sperounes, Gregory \(Gregory\)" <sperounes at
avaya.com<sperounes@DOMAIN.HIDDEN>>
wrote:
>
>
>
> Review of draft-ietf-xcon-framework-06:
>
> ------
> In 9.4.1
>
> "Alice" and "Bob" would remain on the roster of the main conference such
> that the other participants would be unaware of the sidebar.
>
> -------
>
> -------
> The statement above should probably state:
>
> "Alice" and "Bob" would remain on the roster of the main conference such
> that other participants could be aware of their participation in the main
> conference while an internal-sidebar conference (or whisper) is occurring.
>
> -------
>

[MB] Agreed. I'll make this change.

 The state of internal/external sidebar should be used to denote
> main-conference audio mixing while in a sidebar conference.
>
> The concern at the heart of this comment is for clarity of state in the
> framework.
>
> An application can expose the whisper state, or show it as a kind of muted
> state, or hide the whisper state entirely, but the framework should expose a
> very clear state of all participants and conferences and sidebars, without
> inferring or hiding state.
>
> I completely agree with the concept of remaining on the meeting roster,
> because the participation in the meeting, is separate from being in
>
> a room or sidebar.
>
> Can the notifications that a client receives, be
> managed/filtered/interpreted, by the focus based on the role of the client
> after authentication and authorization?
>
[MB] Yes, that's the intent and I think it's fairly clear per the text in
section 8.2 (Notifications).  I could further expand the text that I have in
the examples where it mentions that notifications are sent to indicate that
it is, of course, also based on the role, etc. if folks think that's
necessary?
[/MB]


> Some means of  interpreting state changes before notifying particular
> clients should exist, so long as the heart of the framework provides a clear
> indication of all states.
>
> -------
> In the next section 9.4.2, there is a suggestion that the external-sidebar
> state be denoted by a hold-state indication.
>
> "Alice" initiates the sidebar by sending a request to the conferencing
> system to create a conference reservation based upon the active conference
> object.  "Alice", "Bob" and "Ethel" would remain on the roster of the main
> conference in a hold state."
>
> -------
>
> The same concern and comment applies:
>
> The framework should be able to clearly expose the external-sidebar state
> and allow the application to interpret and present that as an
> external-sidebar state, a hold-state, a locked sidebar state, or some other
> sidebar state. If there is some means by which the actual state can be
> converted or interpreted for specific clients that should be identified as
> separate from the actual framework behavior and state information.
>
> The heart of the framework should not be masking, or inferring state, when
> the actual state is much clearer and provides a more powerful means of
> controlling, and negotiating end user perceptions and options.
>
> In the two examples of internal and external sidebars, the state shown in
> the roster, may collide in undesirable ways with self-muted and chair-muted,
> or self-held and chair-held states, when participants are actually in
> sidebars, or when they return form sidebars, or when more superior
> applications would benefit from the clarity of sidebar state information for
> security purposes.
>
> ----------
> Along this line of reasoning:
>
> The framework should be able to clearly expose the cause of appearing to
> be muted in a conference
> as a result of being a self-muted, a chair-muted (or silenced) , an
> operator-muted, conference-feature-muted (lecture, mute-all, Q&A), or
> menu-muted (for DTMF commands, or IVR routines).
>
> All of these mutes for a participant overlap and become important
> information for superb application experiences.
> The end user may only see isMuted as a light on their screen, the
> framework should be able to individually
> manipulate the various overlapping and intermingling causes for a mute
> state.
>
> I may be interpreting the framework draft examples too precisely.
> I thought it would be worth mentioning in case the boundary between
> framework state and end-user experience are being blurred.
>
[MB]  The basic intent of these examples in the  framework document was to
show how the logical elements fit together and the basic flow of control
between the different logical functions and the messaging at a high level.
The actual details of the data to be manipulated by the framework and the
data to be sent over the signaling interfaces is out of scope and will be
defined by the detailed data model and the detailed specification of the
conference control protocol and any new conference event packages that are
determined to be necessary for the notifications.  The introductory text in
section 9 is intended to set the scope for the examples.  In reality we will
need a much more detailed set of scenarios to show the exact details from
the data model and conference control protocol once those details are all
worked out.   I should perhaps change that first sentence to be very
explicit that the states mentioned in these scenarios are also for
illustrative purposes and do not necessarily reflect the detailed states
represented in the data model, something like the following:
OLD:
The details shown in the messages are for illustrative purposes only and
don't reflect the structure of the conference control protocol messages, but
rather provide a high level primitive view of the necessary operations and
general logic flow, including the data manipulation aspects.

NEW:
The scenarios provide a high level primitive view of the necessary
operations and general logic flow. The details shown in the scenarios are
for illustrative purposes only and don't necessarily reflect the actual
structure of the conference control protocol messages nor the detailed data,
including states, which are defined in separate documents.
[/MB]



 Greg Sperounes
> Conferencing API Team, GCS/UCD
> Avaya Inc
> +1-978-677-5096
>
> Included: Referenced excerpts in context
>
> 9.4.1.  Internal Sidebar
>
>    Figure 12 provides an example of one client "Alice" involved in
>    active conference with "Bob" and "Carol".  "Alice" wants to create a
>    sidebar to have a side discussion with "Bob" while still viewing the
>    video associated with the main conference.  Alternatively, the audio
>    from the main conference could be maintained at a reduced volume.
>    "Alice" initiates the sidebar by sending a request to the
>    conferencing system to create a conference reservation based upon the
>    active conference object.  "Alice" and "Bob" would remain on the
>    roster of the main conference such that the other participants would
>    be unaware of the sidebar.
>
> 9.4.2.  External Sidebar
>
>    Figure 13 provides an example of one client "Alice" involved in an
>    active conference with "Bob", "Carol", "David" and "Ethel".  "Alice"
>    gets an important text message via a whisper from "Bob" that a
>    critical customer needs to talk to "Alice", "Bob" and "Ethel".
>    "Alice" creates a sidebar to have a side discussion with the customer
>    "Fred" including the participants in the current conference with the
>    exception of "Carol" and "David", who remain in the active
>    conference.  "Alice" initiates the sidebar by sending a request to
>    the conferencing system to create a conference reservation based upon
>    the active conference object.  "Alice", "Bob" and "Ethel" would
>    remain on the roster of the main conference in a hold state.  Whether
>    or not the hold state of these participants is visible to other
>    participants depends upon the individual and local policy.
>
> _______________________________________________
> XCON mailing list
> XCON at ietf.orghttps://www1.ietf.org/mailman/listinfo/xcon
>
>

------=_Part_114809_18888160.1169241658322
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>Hi Gregory,</div>
<div>&nbsp;</div>
<div>Thanks for your comments.&nbsp; I&#39;m replying from my gmail account=
 as my usual email server is down right now.&nbsp; My responses are below [=
MB].</div>
<div>&nbsp;</div>
<div>Just to give folks some time to comment, I&#39;ll wait till noon CST o=
n Monday, January 22nd to submit the updated document. </div>
<div>&nbsp;</div>
<div>Mary. <br><br>&nbsp;</div>
<div><span class=3D"gmail_quote">On 1/18/07,&nbsp;&quot;Sperounes, Gregory =
\(Gregory\)&quot; &lt;<a href=3D"mailto:sperounes@DOMAIN.HIDDEN">sperounes =
at avaya.com</a>&gt; wrote:</span>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div><font face=3D"Arial" size=3D"2"></font>&nbsp;</div>
<div><font face=3D"Arial" size=3D"2"></font>&nbsp;</div>
<div><font face=3D"Arial" size=3D"2">Review of draft-ietf-xcon-framework-06=
:</font> </div>
<p><font face=3D"Arial" size=3D"2">------</font> <br><font face=3D"Arial" s=
ize=3D"2">In 9.4.1 </font></p>
<p><font face=3D"Arial" size=3D"2">&quot;Alice&quot; and &quot;Bob&quot; wo=
uld remain on the roster of the main conference such that the other partici=
pants would be unaware of the sidebar.</font></p>
<p><font face=3D"Arial" size=3D"2">-------</font> </p>
<p><font face=3D"Arial" size=3D"2">-------</font> <br><font face=3D"Arial" =
size=3D"2">The statement above should probably state:</font> </p>
<p><font face=3D"Arial" size=3D"2">&quot;Alice&quot; and &quot;Bob&quot; wo=
uld remain on the roster of the main conference such that other participant=
s could be aware of their participation in the main conference while an int=
ernal-sidebar conference (or whisper) is occurring.=20
</font></p>
<p><font face=3D"Arial" size=3D"2">-------</font></p></blockquote>
<div>&nbsp;</div>
<div>[MB] Agreed. I&#39;ll make this change.</div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<p><font face=3D"Arial" size=3D"2">The state of internal/external sidebar s=
hould be used to denote main-conference audio mixing while in a sidebar con=
ference.</font></p>
<p><font face=3D"Arial" size=3D"2">The concern at the heart of this comment=
 is for clarity of state in the framework.</font> </p>
<p><font face=3D"Arial" size=3D"2">An application can expose the whisper st=
ate, or show it as a kind of muted state, or hide the whisper state entirel=
y, but the framework should expose a very clear state of all participants a=
nd conferences and sidebars, without inferring or hiding state.=20
</font></p>
<p><font face=3D"Arial" size=3D"2">I completely agree with the concept of r=
emaining on the meeting roster, because the participation in the meeting, i=
s separate from being in</font></p>
<p><font face=3D"Arial" size=3D"2">a room or sidebar. </font></p>
<p><font face=3D"Arial" size=3D"2">Can the notifications that a client rece=
ives, be managed/filtered/interpreted, by the focus based on the role of th=
e client after authentication and authorization?</font></p></blockquote>
<div>[MB] Yes, that&#39;s the intent and I think it&#39;s fairly clear per =
the text in section 8.2 (Notifications).&nbsp; I could further expand the t=
ext that I have in the examples where it mentions that notifications are se=
nt to indicate that it is, of course, also based on the role, etc. if folks=
 think that&#39;s necessary?&nbsp;=20
</div>
<div>[/MB]&nbsp;<br>&nbsp;</div>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<p><font face=3D"Arial" size=3D"2">Some means of&nbsp; interpreting state c=
hanges before notifying particular clients should exist, so long as the hea=
rt of the framework provides a clear indication of all states.&nbsp;&nbsp; =
</font></p>
<p><font face=3D"Arial" size=3D"2">-------</font> <br><font face=3D"Arial" =
size=3D"2">In the next section 9.4.2, there is a suggestion that the extern=
al-sidebar state be denoted by a hold-state indication.</font> </p>
<p><font face=3D"Arial" size=3D"2">&quot;Alice&quot; initiates the sidebar =
by sending a request to the conferencing system to create a conference rese=
rvation based upon the active conference object.&nbsp; &quot;Alice&quot;, &=
quot;Bob&quot; and &quot;Ethel&quot; would remain on the roster of the main=
 conference in a hold state.&quot;=20
</font></p>
<p><font face=3D"Arial" size=3D"2">-------</font> </p>
<p><font face=3D"Arial" size=3D"2">The same concern and comment applies:</f=
ont> </p>
<p><font face=3D"Arial" size=3D"2">The framework should be able to clearly =
expose the external-sidebar state and allow the application to interpret an=
d present that as an external-sidebar state, a hold-state, a locked sidebar=
 state, or some other sidebar state. If there is some means by which the ac=
tual state can be converted or interpreted for specific clients that should=
 be identified as separate from the actual framework behavior and state inf=
ormation.=20
</font></p>
<p><font face=3D"Arial" size=3D"2">The heart of the framework should not be=
 masking, or inferring state, when the actual state is much clearer and pro=
vides a more powerful means of controlling, and negotiating end user percep=
tions and options.=20
</font></p>
<p><font face=3D"Arial" size=3D"2">In the two examples of internal and exte=
rnal sidebars, the state shown in the roster, may collide in undesirable wa=
ys with self-muted and chair-muted, or self-held and chair-held states, whe=
n participants are actually in sidebars, or when they return form sidebars,=
 or when more superior applications would benefit from the clarity of sideb=
ar state information for security purposes.=20
</font></p>
<p><font face=3D"Arial" size=3D"2">----------</font> <br><font face=3D"Aria=
l" size=3D"2">Along this line of reasoning:</font> <br><br><font face=3D"Ar=
ial" size=3D"2">The framework should be able to clearly expose the cause of=
 appearing to be muted in a conference=20
</font><br><font face=3D"Arial" size=3D"2">as a result of being a self-mute=
d, a chair-muted (or silenced) , an operator-muted, conference-feature-mute=
d (lecture, mute-all, Q&amp;A), or menu-muted (for DTMF commands, or IVR ro=
utines).=20
</font></p>
<p><font face=3D"Arial" size=3D"2">All of these mutes for a participant ove=
rlap and become important information for superb application experiences.</=
font> <br><font face=3D"Arial" size=3D"2">The end user may only see isMuted=
 as a light on their screen, the framework should be able to individually=
=20
</font><br><font face=3D"Arial" size=3D"2">manipulate the various overlappi=
ng and intermingling causes for a mute state.</font> </p>
<p><font face=3D"Arial" size=3D"2">I may be interpreting the framework draf=
t examples too precisely.</font> <br><font face=3D"Arial" size=3D"2">I thou=
ght it would be worth mentioning in case the boundary between framework sta=
te and end-user experience are being blurred.=20
</font></p></blockquote>
<div>[MB]&nbsp; The basic intent of these examples in the &nbsp;framework d=
ocument&nbsp;was to show how the logical elements fit together and the basi=
c flow of control between the different logical functions and the messaging=
 at a high level.&nbsp; The actual details of the data to be manipulated by=
 the framework and the data to be sent over the signaling interfaces is out=
 of scope and will be defined by the detailed data model and the detailed s=
pecification of the conference control protocol and any new conference even=
t packages that are determined to be necessary for the notifications.&nbsp;=
&nbsp;The introductory text in section 9 is intended to set the scope for t=
he examples.&nbsp; In reality we&nbsp;will need a much more detailed set of=
&nbsp;scenarios to show the exact details from the data model and conferenc=
e control protocol once those details are all worked out.&nbsp;&nbsp;&nbsp;=
I should perhaps change that first sentence to be very explicit that the st=
ates mentioned in these scenarios are also for illustrative purposes and do=
 not necessarily reflect the detailed states represented in the data model,=
 something like the following:
</div>
<div>OLD:</div>
<div>The details shown in the messages are for illustrative purposes only a=
nd don&#39;t reflect the structure of the conference control protocol messa=
ges, but rather provide a high level primitive view of the necessary operat=
ions and general logic flow, including the data manipulation aspects.
</div>
<div>&nbsp;</div>
<div>NEW:</div>
<div>The scenarios provide a high level primitive view of the necessary ope=
rations and general logic flow. The details shown in the scenarios&nbsp;are=
 for illustrative purposes only and don&#39;t necessarily reflect the actua=
l structure of the conference control protocol messages nor the detailed da=
ta, including states, which are defined in separate documents.=20
</div>
<div>[/MB]</div>
<div>&nbsp;</div>
<div>&nbsp;</div><br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<p><font face=3D"Arial" size=3D"2">Greg Sperounes</font> <br><font face=3D"=
Arial" size=3D"2">Conferencing API Team, GCS/UCD</font> <br><font face=3D"A=
rial" size=3D"2">Avaya Inc</font> <br><font face=3D"Arial" size=3D"2">+1-97=
8-677-5096</font>
 </p>
<p><font face=3D"Arial" size=3D"2">Included: Referenced excerpts in context=
</font> </p>
<p><font face=3D"Arial" size=3D"2">9.4.1.&nbsp; Internal Sidebar</font> </p=
>
<p><font face=3D"Arial" size=3D"2">&nbsp;&nbsp; Figure 12 provides an examp=
le of one client &quot;Alice&quot; involved in</font> <br><font face=3D"Ari=
al" size=3D"2">&nbsp;&nbsp; active conference with &quot;Bob&quot; and &quo=
t;Carol&quot;.&nbsp; &quot;Alice&quot; wants to create a=20
</font><br><font face=3D"Arial" size=3D"2">&nbsp;&nbsp; sidebar to have a s=
ide discussion with &quot;Bob&quot; while still viewing the</font> <br><fon=
t face=3D"Arial" size=3D"2">&nbsp;&nbsp; video associated with the main con=
ference.&nbsp; Alternatively, the audio=20
</font><br><font face=3D"Arial" size=3D"2">&nbsp;&nbsp; from the main confe=
rence could be maintained at a reduced volume.</font> <br><font face=3D"Ari=
al" size=3D"2">&nbsp;&nbsp; &quot;Alice&quot; initiates the sidebar by send=
ing a request to the</font>
 <br><font face=3D"Arial" size=3D"2">&nbsp;&nbsp; conferencing system to cr=
eate a conference reservation based upon the</font> <br><font face=3D"Arial=
" size=3D"2">&nbsp;&nbsp; active conference object.&nbsp; &quot;Alice&quot;=
 and &quot;Bob&quot; would remain on the=20
</font><br><font face=3D"Arial" size=3D"2">&nbsp;&nbsp; roster of the main =
conference such that the other participants would</font> <br><font face=3D"=
Arial" size=3D"2">&nbsp;&nbsp; be unaware of the sidebar.</font> </p><br>
<p><font face=3D"Arial" size=3D"2">9.4.2.&nbsp; External Sidebar</font> </p=
>
<p><font face=3D"Arial" size=3D"2">&nbsp;&nbsp; Figure 13 provides an examp=
le of one client &quot;Alice&quot; involved in an</font> <br><font face=3D"=
Arial" size=3D"2">&nbsp;&nbsp; active conference with &quot;Bob&quot;, &quo=
t;Carol&quot;, &quot;David&quot; and &quot;Ethel&quot;.&nbsp; &quot;Alice&q=
uot;=20
</font><br><font face=3D"Arial" size=3D"2">&nbsp;&nbsp; gets an important t=
ext message via a whisper from &quot;Bob&quot; that a</font> <br><font face=
=3D"Arial" size=3D"2">&nbsp;&nbsp; critical customer needs to talk to &quot=
;Alice&quot;, &quot;Bob&quot; and &quot;Ethel&quot;.=20
</font><br><font face=3D"Arial" size=3D"2">&nbsp;&nbsp; &quot;Alice&quot; c=
reates a sidebar to have a side discussion with the customer</font> <br><fo=
nt face=3D"Arial" size=3D"2">&nbsp;&nbsp; &quot;Fred&quot; including the pa=
rticipants in the current conference with the=20
</font><br><font face=3D"Arial" size=3D"2">&nbsp;&nbsp; exception of &quot;=
Carol&quot; and &quot;David&quot;, who remain in the active</font> <br><fon=
t face=3D"Arial" size=3D"2">&nbsp;&nbsp; conference.&nbsp; &quot;Alice&quot=
; initiates the sidebar by sending a request to=20
</font><br><font face=3D"Arial" size=3D"2">&nbsp;&nbsp; the conferencing sy=
stem to create a conference reservation based upon</font> <br><font face=3D=
"Arial" size=3D"2">&nbsp;&nbsp; the active conference object.&nbsp; &quot;A=
lice&quot;, &quot;Bob&quot; and &quot;Ethel&quot; would=20
</font><br><font face=3D"Arial" size=3D"2">&nbsp;&nbsp; remain on the roste=
r of the main conference in a hold state.&nbsp; Whether</font> <br><font fa=
ce=3D"Arial" size=3D"2">&nbsp;&nbsp; or not the hold state of these partici=
pants is visible to other</font>
 <br><font face=3D"Arial" size=3D"2">&nbsp;&nbsp; participants depends upon=
 the individual and local policy.</font> </p><br><pre>_____________________=
__________________________
XCON mailing list
XCON at <a onclick=3D"return top.js.OpenExtLink(window,event,this)" href=3D=
"http://ietf.org/" target=3D"_blank">ietf.org</a>
<a onclick=3D"return top.js.OpenExtLink(window,event,this)" href=3D"https:/=
/www1.ietf.org/mailman/listinfo/xcon" target=3D"_blank"><font color=3D"#800=
080">https://www1.ietf.org/mailman/listinfo/xcon</font></a>
</pre></blockquote></div><br>

------=_Part_114809_18888160.1169241658322--


--===============0000289294==
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://www1.ietf.org/mailman/listinfo/xcon

--===============0000289294==--




From xcon-bounces@ietf.org Tue Jan 23 15:50:37 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9SbB-0006Rj-Mc; Tue, 23 Jan 2007 15:50:33 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9Sai-0006JY-V3; Tue, 23 Jan 2007 15:50:04 -0500
Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1H9Sag-00064I-Kl; Tue, 23 Jan 2007 15:50:04 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 66F2326F06;
	Tue, 23 Jan 2007 20:50:02 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1H9Sag-00044M-6H; Tue, 23 Jan 2007 15:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1H9Sag-00044M-6H@stiedprstage1.ietf.org>
Date: Tue, 23 Jan 2007 15:50:02 -0500
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: xcon@ietf.org
Subject: [XCON] I-D ACTION:draft-ietf-xcon-framework-07.txt 
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
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		: A Framework and Data Model for Centralized Conferencing
	Author(s)	: M. Barnes, et al.
	Filename	: draft-ietf-xcon-framework-07.txt
	Pages		: 62
	Date		: 2007-1-23
	
This document defines the framework for Centralized Conferencing.
   The framework allows participants using various call signaling
   protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in
   a centralized unicast conference.  The Centralized Conferencing
   Framework defines logical entities and naming conventions, along with
   a conferencing data model.  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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-07.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-xcon-framework-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-xcon-framework-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2007-1-23125146.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-xcon-framework-07.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-xcon-framework-07.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-1-23125146.I-D@ietf.org>


--OtherAccess--

--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://www1.ietf.org/mailman/listinfo/xcon

--NextPart--




From xcon-bounces@ietf.org Wed Jan 24 11:12:34 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9kji-0003iA-3i; Wed, 24 Jan 2007 11:12:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H9kjg-0003i0-Or
	for xcon@ietf.org; Wed, 24 Jan 2007 11:12:32 -0500
Received: from nj300815-ier2.net.avaya.com ([198.152.12.103])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9kjW-0008FE-3g
	for xcon@ietf.org; Wed, 24 Jan 2007 11:12:32 -0500
Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com
	[198.152.6.52])
	by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP
	id l0OGCJek019348
	for <xcon@ietf.org>; Wed, 24 Jan 2007 11:12:19 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: [XCON] data-model-03 comments - non-runtime data
Date: Wed, 24 Jan 2007 11:12:19 -0500
Message-ID: <6900257941B31D4A954C71DEF805B9A20BE07BBE@nj7460avexu2.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [XCON] data-model-03 comments - non-runtime data
Thread-Index: Acc/0msETUyfXYZKQJGL5LYEUFui0Q==
From: "Braudes, Robert \(Bob\)" <braudes@avaya.com>
To: "XCON-IETF" <xcon@ietf.org>
X-Scanner: InterScan AntiVirus for Sendmail
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0048198941=="
Errors-To: xcon-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0048198941==
content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C73FD2.6C0C2D60"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C73FD2.6C0C2D60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

When reviewing the draft, I have a concern that the current data model
is focused on the runtime aspects of conferencing, and doesn't include
data needed for provisioning new users, accessing CDRs/IPDRs, scheduling
one-time and recurring conferences, managing blueprints, or other pre-
and post-conference activities.  Before making suggested changes to the
document, I would like to hear from others as I am anticipating
proposing a fairly large number of additions to the model.
=20
Thanks,
=20
Bob
=20
Bob Braudes | Consulting Member of the Technical Staff | Conferencing
and Collaboration |=20
Avaya | 150 Apollo Drive | Chelmsford, MA 01824 | W: +1 978 677 5031 M:
+1 978 973 5199 | braudes@avaya.com
=20

------_=_NextPart_001_01C73FD2.6C0C2D60
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D755121314-24012007><FONT face=3DVerdana =
color=3D#000080 size=3D2>When=20
reviewing the draft, I have a concern that the current data model is =
focused on=20
the runtime aspects of conferencing, and doesn't include data needed for =

provisioning new users, accessing CDRs/IPDRs, scheduling one-time and =
recurring=20
conferences, managing blueprints, or other pre- and post-conference=20
activities.&nbsp;&nbsp;Before&nbsp;making suggested changes to the =
document, I=20
would like to hear from others as I am anticipating proposing a fairly =
large=20
number of additions to the model.</FONT></SPAN></DIV>
<DIV><SPAN class=3D755121314-24012007><FONT face=3DVerdana =
color=3D#000080=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D755121314-24012007><FONT face=3DVerdana =
color=3D#000080=20
size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D755121314-24012007><FONT face=3DVerdana =
color=3D#000080=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D755121314-24012007><FONT face=3DVerdana =
color=3D#000080=20
size=3D2>Bob</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV align=3Dleft><FONT color=3D#808080 size=3D2>Bob Braudes <FONT=20
color=3D#ff0000>|</FONT> Consulting Member of the Technical Staff <FONT=20
color=3D#ff0000>|</FONT>&nbsp;Conferencing and Collaboration <FONT=20
color=3D#ff0000>|</FONT>&nbsp;</FONT></DIV>
<DIV align=3Dleft><FONT color=3D#808080 size=3D2>Avaya <FONT =
color=3D#ff0000>|</FONT>=20
150 Apollo Drive <FONT color=3D#ff0000>|</FONT> Chelmsford, MA 01824 =
<FONT=20
color=3D#ff0000>|</FONT> W: +1 978 677 5031 M: +1 978 973 5199<FONT =
color=3D#ff0000>=20
|</FONT> braudes@avaya.com</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C73FD2.6C0C2D60--


--===============0048198941==
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://www1.ietf.org/mailman/listinfo/xcon

--===============0048198941==--




From xcon-bounces@ietf.org Thu Jan 25 01:01:46 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9xg7-0000xR-9G; Thu, 25 Jan 2007 01:01:43 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H9xg5-0000wI-IA
	for xcon@ietf.org; Thu, 25 Jan 2007 01:01:41 -0500
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9xg2-0000Gv-S9
	for xcon@ietf.org; Thu, 25 Jan 2007 01:01:41 -0500
Received: from mailgw4.ericsson.se (unknown [127.0.0.1])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	C94F1212C7; Thu, 25 Jan 2007 07:00:02 +0100 (CET)
X-AuditID: c1b4fb3e-b16d6bb0000007e1-99-45b847627051 
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	B3E7921543; Thu, 25 Jan 2007 07:00:02 +0100 (CET)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 25 Jan 2007 07:00:02 +0100
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 25 Jan 2007 07:00:01 +0100
Received: from [131.160.36.66] (EH3I2003TGFCPET-131160036066.lmf.ericsson.se
	[131.160.36.66])
	by mail.lmf.ericsson.se (Postfix) with ESMTP id A7B28271F;
	Thu, 25 Jan 2007 08:00:01 +0200 (EET)
Message-ID: <45B84760.2060502@ericsson.com>
Date: Thu, 25 Jan 2007 08:00:00 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: XCON <xcon@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 Jan 2007 06:00:01.0862 (UTC)
	FILETIME=[0D508E60:01C74046]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: Dave.Morgan@fmr.com, roni.even@polycom.co.il
Subject: [XCON] Policies in the data model
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

Hi,

we are preparing a new revision of the data model draft and would like
to discuss how to encode policies. The current revision of the draft
uses the concept of roles, which are ordered by their predefined
priority. Each element in the data model have a read-only and a
read-write attributes that specify which is the minimum priority (i.e.,
role) a user needs to read or modify, respectively, the contents of the
element.

We believe that the roles are not defined clearly enough in the draft
and that we need a more flexible way to convey policies in conference
documents.

Our proposal would be to remove the concept of ordered roles and use
unordered groups instead. It would be possible, then, to assign
different rights to different groups.

Another thing we would like to have is documents whose policies are easy
to read (and understand) by humans. Therefore, we would like to be able
to assign a certain policy to the main elements of the data model (i.e.,
the elements directly under the <conference-info> element) and only be
able to make it stricter (i.e., not to relax it) for their child
elements. This way, by simply checking the main elements, it will be
easy to understand whether or not the policy in the document meets the
policy requirements of the conference's administrator.

The resulting XML format would be something like this:

<main-element>
     <access type="read-write">
         <group>2</group>
         <group>3</group>
         <user>bob</user>
     </access>
     <sub-element-1>
         <access-restriction type="read-write">
             <group>3</group>
         </access-restriction>

         [contents of sub-element-1]

     </sub-element-1>
     <sub-element-2>
         <access-restriction type="read-write">
             <user>bob</user>
         </access-restriction>

         [contents of sub-element-2]

     </sub-element-2>
     <sub-element-3>

         [contents of sub-element-3]

     </sub-element-3>

</main-element>

In the example above, the contents of <sub-element-1> can be modified by
users in group 2 and Bob, the contents of <sub-element-2> can be
modified by users in groups 2 and 3, and the contents of <sub-element-3>
can be modified by users in groups 2 and 3, and Bob.

Comments?

Cheers,

Gonzalo

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Thu Jan 25 01:06:39 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9xks-0002nh-Mi; Thu, 25 Jan 2007 01:06:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H9xkr-0002mP-Q3
	for xcon@ietf.org; Thu, 25 Jan 2007 01:06:37 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9xkm-0001SM-7J
	for xcon@ietf.org; Thu, 25 Jan 2007 01:06:37 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	8D01F20665; Thu, 25 Jan 2007 07:06:23 +0100 (CET)
X-AuditID: c1b4fb3c-b17cbbb0000007de-6b-45b848dfb575 
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	7DBCF205FA; Thu, 25 Jan 2007 07:06:23 +0100 (CET)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 25 Jan 2007 07:06:22 +0100
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 25 Jan 2007 07:06:22 +0100
Received: from [131.160.36.66] (EH3I2003TGFCPET-131160036066.lmf.ericsson.se
	[131.160.36.66])
	by mail.lmf.ericsson.se (Postfix) with ESMTP id E788B236E;
	Thu, 25 Jan 2007 08:06:22 +0200 (EET)
Message-ID: <45B848DE.4070100@ericsson.com>
Date: Thu, 25 Jan 2007 08:06:22 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: "Braudes, Robert \(Bob\)" <braudes@avaya.com>
Subject: Re: [XCON] data-model-03 comments - non-runtime data
References: <6900257941B31D4A954C71DEF805B9A20BE07BBE@nj7460avexu2.global.avaya.com>
In-Reply-To: <6900257941B31D4A954C71DEF805B9A20BE07BBE@nj7460avexu2.global.avaya.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 25 Jan 2007 06:06:23.0062 (UTC)
	FILETIME=[F0870F60:01C74046]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Cc: XCON-IETF <xcon@ietf.org>
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

Hi Bob,

the data model will contain the elements needed by most basic 
conferences. That is, the data model intends to be the maximum common 
denominator of all conferences, plus maybe a few additions of elements 
used by many conferences (but not necessarily by all).

Therefore, what we need to discuss is whether the stuff you have in mind 
belongs to the data model itself or to an extension.

Cheers,

Gonzalo


Braudes, Robert (Bob) wrote:
> When reviewing the draft, I have a concern that the current data model 
> is focused on the runtime aspects of conferencing, and doesn't include 
> data needed for provisioning new users, accessing CDRs/IPDRs, scheduling 
> one-time and recurring conferences, managing blueprints, or other pre- 
> and post-conference activities.  Before making suggested changes to the 
> document, I would like to hear from others as I am anticipating 
> proposing a fairly large number of additions to the model.
>  
> Thanks,
>  
> Bob
>  
> Bob Braudes | Consulting Member of the Technical Staff | Conferencing 
> and Collaboration | 
> Avaya | 150 Apollo Drive | Chelmsford, MA 01824 | W: +1 978 677 5031 M: 
> +1 978 973 5199 | braudes@avaya.com
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> XCON mailing list
> XCON@ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon


_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Thu Jan 25 01:48:09 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1H9yOy-0000Kf-9q; Thu, 25 Jan 2007 01:48:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1H9yOt-0000KZ-Qj
	for xcon@ietf.org; Thu, 25 Jan 2007 01:47:59 -0500
Received: from fw.polycom.co.il ([212.179.41.2]
	helo=isrexch01.israel.polycom.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9yOs-0003Mg-DK
	for xcon@ietf.org; Thu, 25 Jan 2007 01:47:59 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [XCON] data-model-03 comments - non-runtime data
Date: Thu, 25 Jan 2007 08:48:02 +0200
Message-ID: <144ED8561CE90C41A3E5908EDECE315C043D893B@IsrExch01.israel.polycom.com>
In-Reply-To: <45B848DE.4070100@ericsson.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [XCON] data-model-03 comments - non-runtime data
Thread-Index: AcdARw4tMH1A5vczTMK72w6sJwv0agABNwLA
From: "Even, Roni" <roni.even@polycom.co.il>
To: "Gonzalo Camarillo" <Gonzalo.Camarillo@ericsson.com>,
	"Braudes, Robert \(Bob\)" <braudes@avaya.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Cc: XCON-IETF <xcon@ietf.org>
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

Hi,
I think that some of the items are covered. Also note that the data =
model is inline with the framework draft and the scenarios (RFC 4597)=20
For scheduling we have iCAL component.
New users for the conference can be defined by adding them to the list =
of participants.
The conference object exists before the conference starts, during the =
conference tile and can be saved by the conferencing server as part of a =
CDR.

I am not sure what you mean by missing elements

Roni Even=20

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]
> Sent: Thursday, January 25, 2007 8:06 AM
> To: Braudes, Robert (Bob)
> Cc: XCON-IETF
> Subject: Re: [XCON] data-model-03 comments - non-runtime data
>=20
> Hi Bob,
>=20
> the data model will contain the elements needed by most basic
> conferences. That is, the data model intends to be the maximum common
> denominator of all conferences, plus maybe a few additions of elements
> used by many conferences (but not necessarily by all).
>=20
> Therefore, what we need to discuss is whether the stuff you have in =
mind
> belongs to the data model itself or to an extension.
>=20
> Cheers,
>=20
> Gonzalo
>=20
>=20
> Braudes, Robert (Bob) wrote:
> > When reviewing the draft, I have a concern that the current data =
model
> > is focused on the runtime aspects of conferencing, and doesn't =
include
> > data needed for provisioning new users, accessing CDRs/IPDRs, =
scheduling
> > one-time and recurring conferences, managing blueprints, or other =
pre-
> > and post-conference activities.  Before making suggested changes to =
the
> > document, I would like to hear from others as I am anticipating
> > proposing a fairly large number of additions to the model.
> >
> > Thanks,
> >
> > Bob
> >
> > Bob Braudes | Consulting Member of the Technical Staff | =
Conferencing
> > and Collaboration |
> > Avaya | 150 Apollo Drive | Chelmsford, MA 01824 | W: +1 978 677 5031 =
M:
> > +1 978 973 5199 | braudes@avaya.com
> >
> >
> >
> > =
------------------------------------------------------------------------
> >
> > _______________________________________________
> > XCON mailing list
> > XCON@ietf.org
> > https://www1.ietf.org/mailman/listinfo/xcon
>=20
>=20
> _______________________________________________
> XCON mailing list
> XCON@ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Thu Jan 25 10:10:48 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HA6FS-0002mh-9l; Thu, 25 Jan 2007 10:10:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HA6FQ-0002mO-NW
	for xcon@ietf.org; Thu, 25 Jan 2007 10:10:44 -0500
Received: from co300216-ier2.net.avaya.com ([198.152.13.103])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA6FO-0002GW-AM
	for xcon@ietf.org; Thu, 25 Jan 2007 10:10:44 -0500
Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com
	[198.152.6.52])
	by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP
	id l0PFAfhU011565
	for <xcon@ietf.org>; Thu, 25 Jan 2007 10:10:41 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [XCON] data-model-03 comments - non-runtime data
Date: Thu, 25 Jan 2007 10:10:39 -0500
Message-ID: <6900257941B31D4A954C71DEF805B9A20BE39F02@nj7460avexu2.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [XCON] data-model-03 comments - non-runtime data
Thread-Index: AcdARw4tMH1A5vczTMK72w6sJwv0agABNwLAAA/2LSA=
From: "Braudes, Robert \(Bob\)" <braudes@avaya.com>
To: "Even, Roni" <roni.even@polycom.co.il>,
	"Gonzalo Camarillo" <Gonzalo.Camarillo@ericsson.com>
X-Scanner: InterScan AntiVirus for Sendmail
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
Cc: XCON-IETF <xcon@ietf.org>
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

Hi Camarillo and Roni,

	Thanks for your comments.  I apologize for missing the iCal
reference in Section 3.3.1, and was thinking that this was only the time
of the current instance rather than for a conference series.  My larger
concerns are how to build an end-to-end conferencing system with this
data model.  For example, how are the blueprints available on a
conference server accessed or modified?  While there is a reference to
CDRs in section 3.3, <conference-description, it is mentioned that the
conference control protocol is used to access CDRs, but I'm not sure how
this is accomplished if there are no CDRs in the data model.  Similarly,
usage data is often required by our Customers, but I don't see where
this is included in the data model.  We could have a separate extension
to this data model, and that was actually my first thought, but it was
suggested that this should be included in the base model.  I am very
willing to write up a proposed extension if this is the direction that
the Working Group would like to take.

Thanks,

Bob

-----Original Message-----
From: Even, Roni [mailto:roni.even@polycom.co.il]=20
Sent: Thursday, January 25, 2007 1:48 AM
To: Gonzalo Camarillo; Braudes, Robert (Bob)
Cc: XCON-IETF
Subject: RE: [XCON] data-model-03 comments - non-runtime data

Hi,
I think that some of the items are covered. Also note that the data
model is inline with the framework draft and the scenarios (RFC 4597)
For scheduling we have iCAL component.
New users for the conference can be defined by adding them to the list
of participants.
The conference object exists before the conference starts, during the
conference tile and can be saved by the conferencing server as part of a
CDR.

I am not sure what you mean by missing elements

Roni Even=20

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]
> Sent: Thursday, January 25, 2007 8:06 AM
> To: Braudes, Robert (Bob)
> Cc: XCON-IETF
> Subject: Re: [XCON] data-model-03 comments - non-runtime data
>=20
> Hi Bob,
>=20
> the data model will contain the elements needed by most basic=20
> conferences. That is, the data model intends to be the maximum common=20
> denominator of all conferences, plus maybe a few additions of elements

> used by many conferences (but not necessarily by all).
>=20
> Therefore, what we need to discuss is whether the stuff you have in=20
> mind belongs to the data model itself or to an extension.
>=20
> Cheers,
>=20
> Gonzalo
>=20
>=20
> Braudes, Robert (Bob) wrote:
> > When reviewing the draft, I have a concern that the current data=20
> > model is focused on the runtime aspects of conferencing, and doesn't

> > include data needed for provisioning new users, accessing=20
> > CDRs/IPDRs, scheduling one-time and recurring conferences, managing=20
> > blueprints, or other pre- and post-conference activities.  Before=20
> > making suggested changes to the document, I would like to hear from=20
> > others as I am anticipating proposing a fairly large number of
additions to the model.
> >
> > Thanks,
> >
> > Bob
> >
> > Bob Braudes | Consulting Member of the Technical Staff |=20
> > Conferencing and Collaboration | Avaya | 150 Apollo Drive |=20
> > Chelmsford, MA 01824 | W: +1 978 677 5031 M:
> > +1 978 973 5199 | braudes@avaya.com
> >
> >
> >
> > --------------------------------------------------------------------
> > ----
> >
> > _______________________________________________
> > XCON mailing list
> > XCON@ietf.org
> > https://www1.ietf.org/mailman/listinfo/xcon
>=20
>=20
> _______________________________________________
> XCON mailing list
> XCON@ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon


_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Thu Jan 25 11:34:38 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HA7Yb-0005v7-PG; Thu, 25 Jan 2007 11:34:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HA7Ya-0005v0-Ix
	for xcon@ietf.org; Thu, 25 Jan 2007 11:34:36 -0500
Received: from webmail.unina.it ([192.132.34.212])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA7YL-00028A-IV
	for xcon@ietf.org; Thu, 25 Jan 2007 11:34:36 -0500
Received: from webmail.unina.it (localhost [127.0.0.1])
	by webmail.unina.it (8.12.11/8.12.11) with ESMTP id l0PGasY6004317;
	Thu, 25 Jan 2007 17:36:54 +0100
Received: (from nobody@localhost)
	by webmail.unina.it (8.12.11/8.12.11/Submit) id l0PGasSW004316;
	Thu, 25 Jan 2007 17:36:54 +0100
X-Authentication-Warning: webmail.unina.it: nobody set sender to
	spromano@unina.it using -f
Received: from 143.225.229.189 ([143.225.229.189]) 
	by webmail.unina.it (IMP) with HTTP 
	for <spromano@192.132.34.41>; Thu, 25 Jan 2007 17:36:54 +0100
Message-ID: <1169743014.45b8dca66c384@webmail.unina.it>
Date: Thu, 25 Jan 2007 17:36:54 +0100
From: Simon Pietro Romano <spromano@unina.it>
To: XCON <xcon@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
User-Agent: Internet Messaging Program (IMP) 3.2.2
X-Originating-IP: 143.225.229.189
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by webmail.unina.it id
	l0PGasY6004317
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: 
Subject: [XCON] Draft on Distributed Conferencing requirements
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

Dear all,

to throw a stone in the lake of discussion, I just submitted a new draft =
on the
"Requirements for Distributed Conferencing". It is also available at the
following site:

http://www.grid.unina.it/draft-ietf-xcon-dcon-requirements-00.txt

We know distributed conferencing is currently out-of-scope in the xcon wo=
rking
group, but we'd really appreciate some feedback about it, given the fact =
that
the core of the work is actually represented by the XCON framework. A fur=
ther
draft about the distributed conferencing framework will be available at t=
he
same site above in the next few days.

Cheers,

Simon
--=20
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department=20
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: spromano@unina.it

    <<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli=20
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/







----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Thu Jan 25 16:25:49 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HAC6M-000207-PD; Thu, 25 Jan 2007 16:25:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HAC6L-0001zr-Jt
	for xcon@ietf.org; Thu, 25 Jan 2007 16:25:45 -0500
Received: from maillnx-us111.fmr.com ([192.223.198.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAC6I-00049c-8V
	for xcon@ietf.org; Thu, 25 Jan 2007 16:25:45 -0500
Received: from MSGMMKSM02WIN.DMN1.FMR.COM (msgmmksm02win.dmn1.fmr.com
	[10.33.139.33])
	by maillnx-us111.fmr.com (Switch-3.1.0/Switch-3.1.0) with SMTP id
	l0PLJpi1030728 for <xcon@ietf.org>; Thu, 25 Jan 2007 16:19:51 -0500
Received: from MSGMMKIV01WIN.DMN1.FMR.COM (10.33.148.30)
	by MSGMMKSM02WIN.DMN1.FMR.COM (Sigaba Gateway v4.0)
	with ESMTP id 119198520; Thu, 25 Jan 2007 16:25:35 -0500
Received: from MSGMROIM02WIN.DMN1.FMR.COM ([172.26.2.195]) by
	MSGMMKIV01WIN.DMN1.FMR.COM with SMTP_server;
	Thu, 25 Jan 2007 16:25:35 -0500
Received: from msgmroclr2win.FMR.COM ([10.37.181.42]) by
	MSGMROIM02WIN.DMN1.FMR.COM with Microsoft SMTPSVC(5.0.2195.6713); 
	Thu, 25 Jan 2007 16:25:34 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 25 Jan 2007 16:25:34 -0500
Message-ID: <2DD4F4320995DB4AA27AFA8D5793F8870286C62C@MSGMROCLR2WIN.DMN1.FMR.COM>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Policies in the data model
thread-index: AcdARkiQO7I01d7YRsiWfXsyzfglOQAdzeDA
References: <45B84760.2060502@ericsson.com>
From: "Morgan, Dave" <Dave.Morgan@FMR.COM>
To: "Gonzalo Camarillo" <Gonzalo.Camarillo@ericsson.com>,
	"XCON" <xcon@ietf.org>
X-OriginalArrivalTime: 25 Jan 2007 21:25:34.0953 (UTC)
	FILETIME=[599DC590:01C740C7]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78
Cc: "Morgan, Dave" <Dave.Morgan@FMR.COM>, roni.even@polycom.co.il
Subject: [XCON] RE: Policies in the data model
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

Gonzalo, this is an interesting proposal let me see if I can accurately
summarize what you are proposing:

1) You propose a method to aggregate users and their privileges called
"groups" in a non-hierarchical manner which replaces the hierarchical
roles that were proposed
2) You propose a method to associate policy directly into the hierarchy
of the data model using an "access" attribute
3) You are introducing inheritance into the data model for sub-elements
with respect to their parent's "access."
4) You allow user names, such as <user>bob</user>, to be directly
specified in the access specification.

If my interpretation is correct, then let me comment on each of the
following:

1) In the prior draft we had policies defined for roles, but now those
policies in essence are being specified in the data model.  I like that
idea, our prior notion of hierarchical roles always seemed to fail when
dealing with exceptions.  But there's nothing that prevents me from
defining a group as <group>moderator</group>.  I'm ok with that, and I'd
prefer to name the element <group> than <role> which would only cause
confusion.

Just a couple more questions on the groups.  Who can create a group, who
puts users in a group, and who sets the policies for the group?  For
standard group names such as administrator, moderator, and participant,
maybe the data model can have some default settings.  But how would I
add a group called "remote-students" and what do you think would be the
mechanism to specify their privileges throughout the model?

2) In your example below you use both <access> and <access-restriction>,
I'm not clear on the distinction.  Are you saying in the main element
that you allow access to group2, group3, and bob, but in the sub-element
<access-restriction> for group3 means they are denied read-write access?
Can I draw the conclusion that group2 and bob will still have read-write
access?  So all children inherit the parent's access unless there is a
restriction.  That seems to be an efficient solution.

3) One of the places where the inheritance model has to be thought
through carefully is in the <users> element. We have to make sure that
the data model allows <bob> to change only the attributes we want him to
change such as "display-text" and "language."  But maybe we don't want
him to have read-write access to "allow-users-dynamically" and that
function can only be set by the <group>administrator</group>. =20

A couple of other questions on 3), do we drop the roles from the data
model?  What about the privileges-control-list?  The only thing I liked
about the privileges-control-list was the <validity> element, which
allowed elements to be changed within a time interval.

4) I really like the idea of allowing the user name, "bob" for example,
to be included in the access groups. =20

My overall comment is that we're dealing with a trade-off, either you
assign the read-write policies on the relevant data model elements
within the definition of each individual or group (or role), or you do
the converse and assign the read-write privileges of each individual or
group within the data model element.  Which is more elegant?

Dave


------------------------------------------------------------------------

David P. Morgan, PhD=20
VP, Enterprise Technology & Architecture=20
Fidelity Investments Systems Company=20
Phone: 617 563-2178=20
Fax: 617 385 2122=20
Mailing: 82 Devonshire St, MZ V3C=20
Boston, MA 02109-3614=20
Office: 245 Summer Street, 3rd Floor


-----Original Message-----
From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20
Sent: Thursday, January 25, 2007 1:00 AM
To: XCON
Cc: Oscar Novo; Morgan, Dave; roni.even@polycom.co.il
Subject: Policies in the data model

Hi,

we are preparing a new revision of the data model draft and would like
to discuss how to encode policies. The current revision of the draft
uses the concept of roles, which are ordered by their predefined
priority. Each element in the data model have a read-only and a
read-write attributes that specify which is the minimum priority (i.e.,
role) a user needs to read or modify, respectively, the contents of the
element.

We believe that the roles are not defined clearly enough in the draft
and that we need a more flexible way to convey policies in conference
documents.

Our proposal would be to remove the concept of ordered roles and use
unordered groups instead. It would be possible, then, to assign
different rights to different groups.

Another thing we would like to have is documents whose policies are easy
to read (and understand) by humans. Therefore, we would like to be able
to assign a certain policy to the main elements of the data model (i.e.,
the elements directly under the <conference-info> element) and only be
able to make it stricter (i.e., not to relax it) for their child
elements. This way, by simply checking the main elements, it will be
easy to understand whether or not the policy in the document meets the
policy requirements of the conference's administrator.

The resulting XML format would be something like this:

<main-element>
     <access type=3D"read-write">
         <group>2</group>
         <group>3</group>
         <user>bob</user>
     </access>
     <sub-element-1>
         <access-restriction type=3D"read-write">
             <group>3</group>
         </access-restriction>

         [contents of sub-element-1]

     </sub-element-1>
     <sub-element-2>
         <access-restriction type=3D"read-write">
             <user>bob</user>
         </access-restriction>

         [contents of sub-element-2]

     </sub-element-2>
     <sub-element-3>

         [contents of sub-element-3]

     </sub-element-3>

</main-element>

In the example above, the contents of <sub-element-1> can be modified by
users in group 2 and Bob, the contents of <sub-element-2> can be
modified by users in groups 2 and 3, and the contents of <sub-element-3>
can be modified by users in groups 2 and 3, and Bob.

Comments?

Cheers,

Gonzalo


_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Thu Jan 25 16:35:58 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HACGE-0001PN-Lm; Thu, 25 Jan 2007 16:35:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HACGE-0001PD-10
	for xcon@ietf.org; Thu, 25 Jan 2007 16:35:58 -0500
Received: from fw.polycom.co.il ([212.179.41.2]
	helo=isrexch01.israel.polycom.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HACGC-00063Q-Jw
	for xcon@ietf.org; Thu, 25 Jan 2007 16:35:58 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [XCON] Draft on Distributed Conferencing requirements
Date: Thu, 25 Jan 2007 23:35:49 +0200
Message-ID: <144ED8561CE90C41A3E5908EDECE315C043D8ACF@IsrExch01.israel.polycom.com>
In-Reply-To: <1169743014.45b8dca66c384@webmail.unina.it>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [XCON] Draft on Distributed Conferencing requirements
Thread-Index: AcdAntn8qx4Vzqd5TFKve8PC+MwvNAAKM0hA
From: "Even, Roni" <roni.even@polycom.co.il>
To: "Simon Pietro Romano" <spromano@unina.it>,
	"XCON" <xcon@ietf.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: 
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

Simon,
I looked at the draft and am not sure what the purpose of it is.
If media mixing is out of scope so what is the conference doing.
In the scenario draft when we talk about simple cascading the idea is =
that each focus makes its own mixing decision without any floor control. =
Knowing who the participants are and the conference state by subscribing =
to all the focuses that compose the conference is feasible=20
For the media simple cascading means that the audio mix from one focus =
is sent to the other as an input to the mixing decision. For the video =
it is even more complicated since each focus may select to display =
another participant if it does voice activated switching. This is why =
using floor control in cascaded conference makes it more predictable.
Another direction is to have distributed media using multicast.

Roni Even

> -----Original Message-----
> From: Simon Pietro Romano [mailto:spromano@unina.it]
> Sent: Thursday, January 25, 2007 6:37 PM
> To: XCON
> Subject: [XCON] Draft on Distributed Conferencing requirements
>=20
> Dear all,
>=20
> to throw a stone in the lake of discussion, I just submitted a new =
draft
> on the
> "Requirements for Distributed Conferencing". It is also available at =
the
> following site:
>=20
> http://www.grid.unina.it/draft-ietf-xcon-dcon-requirements-00.txt
>=20
> We know distributed conferencing is currently out-of-scope in the xcon
> working
> group, but we'd really appreciate some feedback about it, given the =
fact
> that
> the core of the work is actually represented by the XCON framework. A
> further
> draft about the distributed conferencing framework will be available =
at
> the
> same site above in the next few days.
>=20
> Cheers,
>=20
> Simon
> --
>                             _\\|//_
>                             ( O-O )
>    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>                     Simon Pietro Romano
>               Universita' di Napoli Federico II
>                  Computer Science Department
>         Phone: +39 081 7683823 -- Fax: +39 081 7684219
>                 e-mail: spromano@unina.it
>=20
>     <<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli
>    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>                          oooO
>    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>                           \ (    (   )
>                            \_)    ) /
>                                  (_/
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>=20
> _______________________________________________
> XCON mailing list
> XCON@ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Thu Jan 25 20:56:18 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HAGJx-0000h9-Pw; Thu, 25 Jan 2007 20:56:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HAGJw-0000gf-N4
	for xcon@ietf.org; Thu, 25 Jan 2007 20:56:04 -0500
Received: from mail1.exchange.microsoft.com ([131.107.1.17]
	helo=mail.exchange.microsoft.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAGH7-0005Fi-3a
	for xcon@ietf.org; Thu, 25 Jan 2007 20:53:11 -0500
Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.211) by
	DF-GWY-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft
	SMTP Server (TLS) id 8.0.685.24; Thu, 25 Jan 2007 17:53:08 -0800
Received: from DF-COLLIE-MSG.exchange.corp.microsoft.com ([10.255.255.1]) by
	df-bhd-02.exchange.corp.microsoft.com ([157.54.71.211]) with mapi;
	Thu, 25 Jan 2007 17:53:08 -0800
From: Srivatsa Srinivasan <srivats@exchange.microsoft.com>
To: 'Gonzalo Camarillo' <Gonzalo.Camarillo@ericsson.com>, 'XCON'
	<xcon@ietf.org>
Date: Thu, 25 Jan 2007 17:53:07 -0800
Subject: RE: [XCON] Policies in the data model
Thread-Topic: [XCON] Policies in the data model
Thread-Index: AcdARotIPchguCOEQHyzxDeKGv4OiQAbHlUw
Message-ID: <CC36E1772A82C34DBE5F75E1CB549DDA36DAF62931@DF-COLLIE-MSG.exchange.corp.microsoft.com>
References: <45B84760.2060502@ericsson.com>
In-Reply-To: <45B84760.2060502@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
Cc: "'Dave.Morgan@fmr.com'" <Dave.Morgan@fmr.com>,
	"'roni.even@polycom.co.il'" <roni.even@polycom.co.il>
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org


This model can be useful for certain, preferably atomic, sub-elements of
the XML schema that pertain to specific conferencing features. Such an
example would be the controls element or elements that control other
aspects of conferencing (like display-text). But, adopting a generic model
for the entire schema without specifying the applicability can be quite
disastrous for inter-op. How would this model solve some of the following:

        - What if one feature maps to one or more XML sub-elements?

        - What if one or more features map to the same XML sub-elements and
         there are differing restrictions to those?

        - What if one feature maps to a certain sub-element of the data mod=
el
           and also to one or more commands (over the control protocol)?

This may be simple for atomic sub-elements of the document and I am okay
with those having such a model (provided we understand how this relates to
roles), but we need to be careful when generalizing this design as it may
yield some pretty complex automata to implement.

Regards,
Srivatsa.


> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]
> Sent: Wednesday, January 24, 2007 10:00 PM
> To: XCON
> Cc: Dave.Morgan@fmr.com; roni.even@polycom.co.il
> Subject: [XCON] Policies in the data model
>
> Hi,
>
> we are preparing a new revision of the data model draft and would like
> to discuss how to encode policies. The current revision of the draft
> uses the concept of roles, which are ordered by their predefined
> priority. Each element in the data model have a read-only and a
> read-write attributes that specify which is the minimum priority (i.e.,
> role) a user needs to read or modify, respectively, the contents of the
> element.
>
> We believe that the roles are not defined clearly enough in the draft
> and that we need a more flexible way to convey policies in conference
> documents.
>
> Our proposal would be to remove the concept of ordered roles and use
> unordered groups instead. It would be possible, then, to assign
> different rights to different groups.
>
> Another thing we would like to have is documents whose policies are
> easy
> to read (and understand) by humans. Therefore, we would like to be able
> to assign a certain policy to the main elements of the data model
> (i.e.,
> the elements directly under the <conference-info> element) and only be
> able to make it stricter (i.e., not to relax it) for their child
> elements. This way, by simply checking the main elements, it will be
> easy to understand whether or not the policy in the document meets the
> policy requirements of the conference's administrator.
>
> The resulting XML format would be something like this:
>
> <main-element>
>      <access type=3D"read-write">
>          <group>2</group>
>          <group>3</group>
>          <user>bob</user>
>      </access>
>      <sub-element-1>
>          <access-restriction type=3D"read-write">
>              <group>3</group>
>          </access-restriction>
>
>          [contents of sub-element-1]
>
>      </sub-element-1>
>      <sub-element-2>
>          <access-restriction type=3D"read-write">
>              <user>bob</user>
>          </access-restriction>
>
>          [contents of sub-element-2]
>
>      </sub-element-2>
>      <sub-element-3>
>
>          [contents of sub-element-3]
>
>      </sub-element-3>
>
> </main-element>
>
> In the example above, the contents of <sub-element-1> can be modified
> by
> users in group 2 and Bob, the contents of <sub-element-2> can be
> modified by users in groups 2 and 3, and the contents of <sub-element-
> 3>
> can be modified by users in groups 2 and 3, and Bob.
>
> Comments?
>
> Cheers,
>
> Gonzalo
>
> _______________________________________________
> XCON mailing list
> XCON@ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Fri Jan 26 02:23:18 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HALQM-0007K2-Dy; Fri, 26 Jan 2007 02:23:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HALQL-0007HA-Kg
	for xcon@ietf.org; Fri, 26 Jan 2007 02:23:01 -0500
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HALQE-0003aw-S0
	for xcon@ietf.org; Fri, 26 Jan 2007 02:23:01 -0500
Received: from mailgw3.ericsson.se (unknown [127.0.0.1])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	0328720522; Fri, 26 Jan 2007 08:22:38 +0100 (CET)
X-AuditID: c1b4fb3c-aefc6bb0000007de-b3-45b9ac3d5bc1 
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	E3619520001; Fri, 26 Jan 2007 08:22:37 +0100 (CET)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 26 Jan 2007 08:22:37 +0100
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 26 Jan 2007 08:22:36 +0100
Received: from [131.160.36.66] (EH3I2003TGFCPET-131160036066.lmf.ericsson.se
	[131.160.36.66])
	by mail.lmf.ericsson.se (Postfix) with ESMTP id CB06D236A;
	Fri, 26 Jan 2007 09:22:36 +0200 (EET)
Message-ID: <45B9AC3B.4080108@ericsson.com>
Date: Fri, 26 Jan 2007 09:22:35 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: "Braudes, Robert \(Bob\)" <braudes@avaya.com>
Subject: Re: [XCON] data-model-03 comments - non-runtime data
References: <6900257941B31D4A954C71DEF805B9A20BE39F02@nj7460avexu2.global.avaya.com>
In-Reply-To: <6900257941B31D4A954C71DEF805B9A20BE39F02@nj7460avexu2.global.avaya.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Jan 2007 07:22:36.0923 (UTC)
	FILETIME=[C12C9CB0:01C7411A]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7
Cc: "Even, Roni" <roni.even@polycom.co.il>, XCON-IETF <xcon@ietf.org>
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

Hi,

I guess we could define all the CDR-related elements in an extension, as 
opposed to the base data model.

Regarding usage data, could you provide us with a couple of examples of 
the elements you would like to define so that we can discuss whether 
they belong to the based data model or to an extension?

Thanks,

Gonzalo


Braudes, Robert (Bob) wrote:
> Hi Camarillo and Roni,
> 
> 	Thanks for your comments.  I apologize for missing the iCal
> reference in Section 3.3.1, and was thinking that this was only the time
> of the current instance rather than for a conference series.  My larger
> concerns are how to build an end-to-end conferencing system with this
> data model.  For example, how are the blueprints available on a
> conference server accessed or modified?  While there is a reference to
> CDRs in section 3.3, <conference-description, it is mentioned that the
> conference control protocol is used to access CDRs, but I'm not sure how
> this is accomplished if there are no CDRs in the data model.  Similarly,
> usage data is often required by our Customers, but I don't see where
> this is included in the data model.  We could have a separate extension
> to this data model, and that was actually my first thought, but it was
> suggested that this should be included in the base model.  I am very
> willing to write up a proposed extension if this is the direction that
> the Working Group would like to take.
> 
> Thanks,
> 
> Bob
> 
> -----Original Message-----
> From: Even, Roni [mailto:roni.even@polycom.co.il] 
> Sent: Thursday, January 25, 2007 1:48 AM
> To: Gonzalo Camarillo; Braudes, Robert (Bob)
> Cc: XCON-IETF
> Subject: RE: [XCON] data-model-03 comments - non-runtime data
> 
> Hi,
> I think that some of the items are covered. Also note that the data
> model is inline with the framework draft and the scenarios (RFC 4597)
> For scheduling we have iCAL component.
> New users for the conference can be defined by adding them to the list
> of participants.
> The conference object exists before the conference starts, during the
> conference tile and can be saved by the conferencing server as part of a
> CDR.
> 
> I am not sure what you mean by missing elements
> 
> Roni Even 
> 
>> -----Original Message-----
>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]
>> Sent: Thursday, January 25, 2007 8:06 AM
>> To: Braudes, Robert (Bob)
>> Cc: XCON-IETF
>> Subject: Re: [XCON] data-model-03 comments - non-runtime data
>>
>> Hi Bob,
>>
>> the data model will contain the elements needed by most basic 
>> conferences. That is, the data model intends to be the maximum common 
>> denominator of all conferences, plus maybe a few additions of elements
> 
>> used by many conferences (but not necessarily by all).
>>
>> Therefore, what we need to discuss is whether the stuff you have in 
>> mind belongs to the data model itself or to an extension.
>>
>> Cheers,
>>
>> Gonzalo
>>
>>
>> Braudes, Robert (Bob) wrote:
>>> When reviewing the draft, I have a concern that the current data 
>>> model is focused on the runtime aspects of conferencing, and doesn't
> 
>>> include data needed for provisioning new users, accessing 
>>> CDRs/IPDRs, scheduling one-time and recurring conferences, managing 
>>> blueprints, or other pre- and post-conference activities.  Before 
>>> making suggested changes to the document, I would like to hear from 
>>> others as I am anticipating proposing a fairly large number of
> additions to the model.
>>> Thanks,
>>>
>>> Bob
>>>
>>> Bob Braudes | Consulting Member of the Technical Staff | 
>>> Conferencing and Collaboration | Avaya | 150 Apollo Drive | 
>>> Chelmsford, MA 01824 | W: +1 978 677 5031 M:
>>> +1 978 973 5199 | braudes@avaya.com
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> ----
>>>
>>> _______________________________________________
>>> XCON mailing list
>>> XCON@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/xcon
>>
>> _______________________________________________
>> XCON mailing list
>> XCON@ietf.org
>> https://www1.ietf.org/mailman/listinfo/xcon
> 


_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Fri Jan 26 04:44:56 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HANdg-0004BX-Ph; Fri, 26 Jan 2007 04:44:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HANdf-0004BS-G1
	for xcon@ietf.org; Fri, 26 Jan 2007 04:44:55 -0500
Received: from mail.unina.it ([192.132.34.73])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HANdb-00071z-9b
	for xcon@ietf.org; Fri, 26 Jan 2007 04:44:55 -0500
Received: from [143.225.229.174] ([143.225.229.174])
	by mail.unina.it (8.13.7/8.13.7) with ESMTP id l0QAhTjI016766;
	Fri, 26 Jan 2007 11:43:31 +0100
Message-ID: <45B9CD53.7000800@libero.it>
Date: Fri, 26 Jan 2007 10:43:47 +0100
From: Lorenzo Miniero <rainmaker@libero.it>
User-Agent: Mozilla Thunderbird 1.5.0.9 (X11/20061219)
MIME-Version: 1.0
To: "Even, Roni" <roni.even@polycom.co.il>
Subject: Re: [XCON] Draft on Distributed Conferencing requirements
References: <144ED8561CE90C41A3E5908EDECE315C043D8ACF@IsrExch01.israel.polycom.com>
In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C043D8ACF@IsrExch01.israel.polycom.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-unina-it-MailScanner-Information: Please contact www.csi.unina.it for
	information
X-unina-it-MailScanner: Found to be clean
X-unina-it-MailScanner-SpamCheck: non spam, SpamAssassin (punteggio=0.018,
	necessario 6, autolearn=disabled, AWL 0.02)
X-unina-it-MailScanner-From: rainmaker@libero.it
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mail.unina.it id
	l0QAhTjI016766
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7
Cc: XCON <xcon@ietf.org>
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

Hi Roni,

> Simon,
> I looked at the draft and am not sure what the purpose of it is.
> If media mixing is out of scope so what is the conference doing.
> In the scenario draft when we talk about simple cascading the idea is t=
hat each focus makes its own mixing decision without any floor control. K=
nowing who the participants are and the conference state by subscribing t=
o all the focuses that compose the conference is feasible=20
>  =20

Actually the problem in just cascading is exactly the lack of mechanisms=20
as floor control. What you say is right, each focus should make its own=20
mixing and exchange it with others: however, if floor control is=20
involved the foci can't ignore the rights to access resources, and this=20
is exactly what we want to accomplish. For example, if the floor control=20
server of the focus hosting the conference (which me might improperly=20
call the "main" focus) hasn't given yet the right to talk to a user=20
belonging to a cascaded (or distributed) conference, the cascaded=20
conference focus will have to exclude the audio of this user from its=20
local mix before sharing it with others. This of course can be done only=20
by an opportune dispatching of BFCP messages among the involved foci,=20
which is what we envisage in our requirements thoughts. Of course the=20
same considerations I just made for BFCP can be made for other XCON=20
protocols (i.e. protocols that are born to live as natively centralized)=20
as well, e.g. for what will be the conference control protocol. The=20
distributed approach we propose is absolutely compliant with the ongoing=20
work in XCON: we basically want to enable the distribution of what is=20
natively centralized without "breaking" anything, and it will probably=20
be much clearer once we'll release the framework draft too.


> For the media simple cascading means that the audio mix from one focus =
is sent to the other as an input to the mixing decision. For the video it=
 is even more complicated since each focus may select to display another =
participant if it does voice activated switching. This is why using floor=
 control in cascaded conference makes it more predictable.
> Another direction is to have distributed media using multicast.
>  =20

The fact that we consider distributed mixing out-of-scope of course=20
doesn't mean we ignore it. On the contrary, we strongly believe it is of=20
great importance, and this is why, as you know, we are following with=20
great interest the newly born MediaCtrl WG too. However, as Eric,=20
MediaCtrl's chair, noticed, distributed mixing is a very hard matter,=20
and while we're studying it as a research matter (as an University,=20
research is our field :) ), we thought that in a framework definition=20
(and in its requirements) it would have been of greater importance=20
focusing on how to distribute the involved signaling and control, and=20
initially considering existing solutions for media distribution. In=20
fact, in the tests we made so far this is exactly what we did: we used=20
existing solutions for basic media distribution amongst the involved=20
parties, e.g. BFCP-moderated exchange of all the foci's local mixes.=20
While our work upon distributed conferencing and our research upon=20
distributed mixing will go on, we will surely make more and more=20
proposals and suggestions upon media distribution as well, but the focus=20
will still remain signaling and control, as happens in XCON as well.

Best regards,
Lorenzo

> Roni Even
>
>  =20
>> -----Original Message-----
>> From: Simon Pietro Romano [mailto:spromano@unina.it]
>> Sent: Thursday, January 25, 2007 6:37 PM
>> To: XCON
>> Subject: [XCON] Draft on Distributed Conferencing requirements
>>
>> Dear all,
>>
>> to throw a stone in the lake of discussion, I just submitted a new dra=
ft
>> on the
>> "Requirements for Distributed Conferencing". It is also available at t=
he
>> following site:
>>
>> http://www.grid.unina.it/draft-ietf-xcon-dcon-requirements-00.txt
>>
>> We know distributed conferencing is currently out-of-scope in the xcon
>> working
>> group, but we'd really appreciate some feedback about it, given the fa=
ct
>> that
>> the core of the work is actually represented by the XCON framework. A
>> further
>> draft about the distributed conferencing framework will be available a=
t
>> the
>> same site above in the next few days.
>>
>> Cheers,
>>
>> Simon
>> --
>>                             _\\|//_
>>                             ( O-O )
>>    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>>                     Simon Pietro Romano
>>               Universita' di Napoli Federico II
>>                  Computer Science Department
>>         Phone: +39 081 7683823 -- Fax: +39 081 7684219
>>                 e-mail: spromano@unina.it
>>
>>     <<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli
>>    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>>                          oooO
>>    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>>                           \ (    (   )
>>                            \_)    ) /
>>                                  (_/
>>
>>
>>
>>
>>
>>
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>>
>> _______________________________________________
>> XCON mailing list
>> XCON@ietf.org
>> https://www1.ietf.org/mailman/listinfo/xcon
>>    =20
>
> _______________________________________________
> XCON mailing list
> XCON@ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon
>
>  =20


--=20
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Universit=E0 degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: lminiero@gmail.com


--=20
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.


_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Sun Jan 28 06:41:52 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HB8Ph-0003t2-J0; Sun, 28 Jan 2007 06:41:37 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HB8Pf-0003su-Qh
	for xcon@ietf.org; Sun, 28 Jan 2007 06:41:35 -0500
Received: from webmail.unina.it ([192.132.34.212])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HB8Pe-0007ng-Bs
	for xcon@ietf.org; Sun, 28 Jan 2007 06:41:35 -0500
Received: from webmail.unina.it (localhost [127.0.0.1])
	by webmail.unina.it (8.12.11/8.12.11) with ESMTP id l0SBinTf030074;
	Sun, 28 Jan 2007 12:44:49 +0100
Received: (from nobody@localhost)
	by webmail.unina.it (8.12.11/8.12.11/Submit) id l0SBinMo030073;
	Sun, 28 Jan 2007 12:44:49 +0100
X-Authentication-Warning: webmail.unina.it: nobody set sender to
	spromano@unina.it using -f
Received: from host248-149-dynamic.11-87-r.retail.telecomitalia.it
	(host248-149-dynamic.11-87-r.retail.telecomitalia.it
	[87.11.149.248]) by webmail.unina.it (IMP) with HTTP 
	for <spromano@192.132.34.41>; Sun, 28 Jan 2007 12:44:49 +0100
Message-ID: <1169984689.45bc8cb1b6b9a@webmail.unina.it>
Date: Sun, 28 Jan 2007 12:44:49 +0100
From: Simon Pietro Romano <spromano@unina.it>
To: XCON <xcon@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
User-Agent: Internet Messaging Program (IMP) 3.2.2
X-Originating-IP: 87.11.149.248
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by webmail.unina.it id
	l0SBinTf030074
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Subject: [XCON] New drafts on Distributed Conferencing
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

Dear all,

we just submitted two new drafts on Distributed Conferencing. You can fin=
d them
at:

1- "A Framework for Distributed COnferencing":
http://dcon.sourceforge.net/docs/draft-ietf-xcon-dcon-framework-00.txt

2- "Requirements for the XCON-DCON Synchronization Protocol" -->
http://dcon.sourceforge.net/docs/draft-ietf-xcon-dcon-xdsp-reqs-00.txt

We're looking forward to receiving your comments.

Cheers,

Simon
--=20
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department=20
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: spromano@unina.it

    <<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli=20
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/







----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Mon Jan 29 02:31:32 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBQzC-00075l-4c; Mon, 29 Jan 2007 02:31:30 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBQzA-00075d-TW
	for xcon@ietf.org; Mon, 29 Jan 2007 02:31:28 -0500
Received: from ihemail3.lucent.com ([135.245.0.37])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBQz7-0000Pg-Hv
	for xcon@ietf.org; Mon, 29 Jan 2007 02:31:28 -0500
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l0T7VELW021200;
	Mon, 29 Jan 2007 01:31:14 -0600 (CST)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 29 Jan 2007 01:31:14 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by
	DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 29 Jan 2007 08:31:11 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [XCON] New drafts on Distributed Conferencing
Date: Mon, 29 Jan 2007 08:31:11 +0100
Message-ID: <5D1A7985295922448D5550C94DE29180BD2F5E@DEEXC1U01.de.lucent.com>
In-Reply-To: <1169984689.45bc8cb1b6b9a@webmail.unina.it>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [XCON] New drafts on Distributed Conferencing
Thread-Index: AcdC0cKjkQoUTHDeSQKV+sJalIP9KgAD7m5g
References: <1169984689.45bc8cb1b6b9a@webmail.unina.it>
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "Simon Pietro Romano" <spromano@unina.it>, "XCON" <xcon@ietf.org>
X-OriginalArrivalTime: 29 Jan 2007 07:31:11.0923 (UTC)
	FILETIME=[7360A030:01C74377]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: 
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

With these filenames I would expect rejection from the secretariat.

I don't remember any discussion to open new WG milestones on this =
subject, which means these cannot be XCON WG items.

Regards

Keith=20

> -----Original Message-----
> From: Simon Pietro Romano [mailto:spromano@unina.it]=20
> Sent: 28 January 2007 11:45
> To: XCON
> Subject: [XCON] New drafts on Distributed Conferencing
>=20
> Dear all,
>=20
> we just submitted two new drafts on Distributed Conferencing.=20
> You can find them
> at:
>=20
> 1- "A Framework for Distributed COnferencing":
> http://dcon.sourceforge.net/docs/draft-ietf-xcon-dcon-framework-00.txt
>=20
> 2- "Requirements for the XCON-DCON Synchronization Protocol"=20
> -->=20
> http://dcon.sourceforge.net/docs/draft-ietf-xcon-dcon-xdsp-reqs-00.txt
>=20
> We're looking forward to receiving your comments.
>=20
> Cheers,
>=20
> Simon
> --=20
>                             _\\|//_
>                             ( O-O )
>    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>                     Simon Pietro Romano
>               Universita' di Napoli Federico II
>                  Computer Science Department=20
>         Phone: +39 081 7683823 -- Fax: +39 081 7684219
>                 e-mail: spromano@unina.it
>=20
>     <<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli=20
>    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>                          oooO
>    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>                           \ (    (   )
>                            \_)    ) /
>                                  (_/
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>=20
> _______________________________________________
> XCON mailing list
> XCON@ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon
>=20

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Mon Jan 29 11:58:19 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBZpe-0003os-RK; Mon, 29 Jan 2007 11:58:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBZpd-0003on-7g
	for xcon@ietf.org; Mon, 29 Jan 2007 11:58:13 -0500
Received: from webmail.unina.it ([192.132.34.212])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBZpY-0006Ze-7S
	for xcon@ietf.org; Mon, 29 Jan 2007 11:58:13 -0500
Received: from webmail.unina.it (localhost [127.0.0.1])
	by webmail.unina.it (8.12.11/8.12.11) with ESMTP id l0TH1Rmu029551;
	Mon, 29 Jan 2007 18:01:27 +0100
Received: (from nobody@localhost)
	by webmail.unina.it (8.12.11/8.12.11/Submit) id l0TH1NUx029550;
	Mon, 29 Jan 2007 18:01:23 +0100
X-Authentication-Warning: webmail.unina.it: nobody set sender to
	spromano@unina.it using -f
Received: from 143.225.229.189 ([143.225.229.189]) 
	by webmail.unina.it (IMP) with HTTP 
	for <spromano@192.132.34.41>; Mon, 29 Jan 2007 18:01:23 +0100
Message-ID: <1170090083.45be2863a79e4@webmail.unina.it>
Date: Mon, 29 Jan 2007 18:01:23 +0100
From: Simon Pietro Romano <spromano@unina.it>
To: "Drage, Keith (Keith)" <drage@alcatel-lucent.com>
Subject: RE: [XCON] New drafts on Distributed Conferencing
References: <1169984689.45bc8cb1b6b9a@webmail.unina.it>
	<5D1A7985295922448D5550C94DE29180BD2F5E@DEEXC1U01.de.lucent.com>
In-Reply-To: <5D1A7985295922448D5550C94DE29180BD2F5E@DEEXC1U01.de.lucent.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
User-Agent: Internet Messaging Program (IMP) 3.2.2
X-Originating-IP: 143.225.229.189
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by webmail.unina.it id
	l0TH1Rmu029551
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Cc: XCON <xcon@ietf.org>
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

Hi Keith,

did you read just the title? What if the filename were:

"A framework to improve XCON scalability throguh focus replication"?

Would this sound more politically correct?

Cheers,

Simon
--=20
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department=20
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: spromano@unina.it

    <<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli=20
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/




Scrive "Drage, Keith (Keith)" <drage@alcatel-lucent.com>:

> With these filenames I would expect rejection from the secretariat.
>=20
> I don't remember any discussion to open new WG milestones on this subje=
ct,
> which means these cannot be XCON WG items.
>=20
> Regards
>=20
> Keith=20
>=20
> > -----Original Message-----
> > From: Simon Pietro Romano [mailto:spromano@unina.it]=20
> > Sent: 28 January 2007 11:45
> > To: XCON
> > Subject: [XCON] New drafts on Distributed Conferencing
> >=20
> > Dear all,
> >=20
> > we just submitted two new drafts on Distributed Conferencing.=20
> > You can find them
> > at:
> >=20
> > 1- "A Framework for Distributed COnferencing":
> > http://dcon.sourceforge.net/docs/draft-ietf-xcon-dcon-framework-00.tx=
t
> >=20
> > 2- "Requirements for the XCON-DCON Synchronization Protocol"=20
> > -->=20
> > http://dcon.sourceforge.net/docs/draft-ietf-xcon-dcon-xdsp-reqs-00.tx=
t
> >=20
> > We're looking forward to receiving your comments.
> >=20
> > Cheers,
> >=20
> > Simon
> > --=20
> >                             _\\|//_
> >                             ( O-O )
> >    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
> >                     Simon Pietro Romano
> >               Universita' di Napoli Federico II
> >                  Computer Science Department=20
> >         Phone: +39 081 7683823 -- Fax: +39 081 7684219
> >                 e-mail: spromano@unina.it
> >=20
> >     <<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli=20
> >    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
> >                          oooO
> >    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
> >                           \ (    (   )
> >                            \_)    ) /
> >                                  (_/
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> > ----------------------------------------------------------------
> > This message was sent using IMP, the Internet Messaging Program.
> >=20
> > _______________________________________________
> > XCON mailing list
> > XCON@ietf.org
> > https://www1.ietf.org/mailman/listinfo/xcon
> >=20
>=20


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Mon Jan 29 12:04:35 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBZvn-0005OS-UE; Mon, 29 Jan 2007 12:04:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBZvm-0005OL-6f
	for xcon@ietf.org; Mon, 29 Jan 2007 12:04:34 -0500
Received: from ebru.winwebhosting.com ([74.52.236.50])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBZvk-0007aU-Ra
	for xcon@ietf.org; Mon, 29 Jan 2007 12:04:34 -0500
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp)
	by ebru.winwebhosting.com with esmtpa (Exim 4.63)
	(envelope-from <br@brianrosen.net>)
	id 1HBZus-0005kZ-Vx; Mon, 29 Jan 2007 11:03:39 -0600
From: "Brian Rosen" <br@brianrosen.net>
To: "'Simon Pietro Romano'" <spromano@unina.it>,
	"'Drage, Keith \(Keith\)'" <drage@alcatel-lucent.com>
Subject: RE: [XCON] New drafts on Distributed Conferencing
Date: Mon, 29 Jan 2007 12:04:30 -0500
Message-ID: <051901c743c7$8c3847c0$640fa8c0@cis.neustar.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
Thread-Index: AcdDxpB8XDFL3s0IQEW8ZYJyxebrEAAAIQ9w
In-Reply-To: <1170090083.45be2863a79e4@webmail.unina.it>
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c
Cc: 'XCON' <xcon@ietf.org>
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

I believe he was referring to the fact that you can't have a file =
starting
with draft-ietf-xcon unless it is already accepted as a work group item.

Since this is your own private draft, it has to have a filename like
draft-romano-xcon-dcon-xdsp-reqs-00

The secretariat is unlikely to accept your draft until you change its =
name.

The title is not something they care about.

Brian

> -----Original Message-----
> From: Simon Pietro Romano [mailto:spromano@unina.it]
> Sent: Monday, January 29, 2007 12:01 PM
> To: Drage, Keith (Keith)
> Cc: XCON
> Subject: RE: [XCON] New drafts on Distributed Conferencing
>=20
> Hi Keith,
>=20
> did you read just the title? What if the filename were:
>=20
> "A framework to improve XCON scalability throguh focus replication"?
>=20
> Would this sound more politically correct?
>=20
> Cheers,
>=20
> Simon
> --
>                             _\\|//_
>                             ( O-O )
>    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>                     Simon Pietro Romano
>               Universita' di Napoli Federico II
>                  Computer Science Department
>         Phone: +39 081 7683823 -- Fax: +39 081 7684219
>                 e-mail: spromano@unina.it
>=20
>     <<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli
>    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>                          oooO
>    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>                           \ (    (   )
>                            \_)    ) /
>                                  (_/
>=20
>=20
>=20
>=20
> Scrive "Drage, Keith (Keith)" <drage@alcatel-lucent.com>:
>=20
> > With these filenames I would expect rejection from the secretariat.
> >
> > I don't remember any discussion to open new WG milestones on this
> subject,
> > which means these cannot be XCON WG items.
> >
> > Regards
> >
> > Keith
> >
> > > -----Original Message-----
> > > From: Simon Pietro Romano [mailto:spromano@unina.it]
> > > Sent: 28 January 2007 11:45
> > > To: XCON
> > > Subject: [XCON] New drafts on Distributed Conferencing
> > >
> > > Dear all,
> > >
> > > we just submitted two new drafts on Distributed Conferencing.
> > > You can find them
> > > at:
> > >
> > > 1- "A Framework for Distributed COnferencing":
> > > =
http://dcon.sourceforge.net/docs/draft-ietf-xcon-dcon-framework-00.txt
> > >
> > > 2- "Requirements for the XCON-DCON Synchronization Protocol"
> > > -->
> > > =
http://dcon.sourceforge.net/docs/draft-ietf-xcon-dcon-xdsp-reqs-00.txt
> > >
> > > We're looking forward to receiving your comments.
> > >
> > > Cheers,
> > >
> > > Simon
> > > --
> > >                             _\\|//_
> > >                             ( O-O )
> > >    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
> > >                     Simon Pietro Romano
> > >               Universita' di Napoli Federico II
> > >                  Computer Science Department
> > >         Phone: +39 081 7683823 -- Fax: +39 081 7684219
> > >                 e-mail: spromano@unina.it
> > >
> > >     <<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli
> > >    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
> > >                          oooO
> > >    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
> > >                           \ (    (   )
> > >                            \_)    ) /
> > >                                  (_/
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ----------------------------------------------------------------
> > > This message was sent using IMP, the Internet Messaging Program.
> > >
> > > _______________________________________________
> > > XCON mailing list
> > > XCON@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/xcon
> > >
> >
>=20
>=20
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>=20
> _______________________________________________
> XCON mailing list
> XCON@ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon


_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Mon Jan 29 12:28:41 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBaJ6-0000yT-V6; Mon, 29 Jan 2007 12:28:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBaJ5-0000s7-Qp
	for xcon@ietf.org; Mon, 29 Jan 2007 12:28:39 -0500
Received: from ihemail4.lucent.com ([135.245.0.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBaJ4-00036J-AL
	for xcon@ietf.org; Mon, 29 Jan 2007 12:28:39 -0500
Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1])
	by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l0THSXxq016928;
	Mon, 29 Jan 2007 11:28:34 -0600 (CST)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by
	ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 29 Jan 2007 11:28:32 -0600
Received: from DEEXC1U01.de.lucent.com ([135.248.187.28]) by
	DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 29 Jan 2007 18:28:27 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [XCON] New drafts on Distributed Conferencing
Date: Mon, 29 Jan 2007 18:28:26 +0100
Message-ID: <5D1A7985295922448D5550C94DE29180BD3425@DEEXC1U01.de.lucent.com>
In-Reply-To: <051901c743c7$8c3847c0$640fa8c0@cis.neustar.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [XCON] New drafts on Distributed Conferencing
Thread-Index: AcdDxpB8XDFL3s0IQEW8ZYJyxebrEAAAIQ9wAADdDkA=
References: <1170090083.45be2863a79e4@webmail.unina.it>
	<051901c743c7$8c3847c0$640fa8c0@cis.neustar.com>
From: "Drage, Keith \(Keith\)" <drage@alcatel-lucent.com>
To: "Brian Rosen" <br@brianrosen.net>,
	"Simon Pietro Romano" <spromano@unina.it>
X-OriginalArrivalTime: 29 Jan 2007 17:28:27.0800 (UTC)
	FILETIME=[E3398180:01C743CA]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407
Cc: XCON <xcon@ietf.org>
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

Exactly.

And the reason for copying the list was so that I could be corrected if =
the discussion really had taken place.

Having submitted an author draft, your next step is to persuade the IETF =
that this is an interesting problem to work on, either within XCON or =
using some other mechanism. The WG chairs should be able to advise you =
on good things to help this happen.

Keith=20

> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]=20
> Sent: 29 January 2007 17:05
> To: 'Simon Pietro Romano'; Drage, Keith (Keith)
> Cc: 'XCON'
> Subject: RE: [XCON] New drafts on Distributed Conferencing
>=20
> I believe he was referring to the fact that you can't have a=20
> file starting with draft-ietf-xcon unless it is already=20
> accepted as a work group item.
>=20
> Since this is your own private draft, it has to have a=20
> filename like draft-romano-xcon-dcon-xdsp-reqs-00
>=20
> The secretariat is unlikely to accept your draft until you=20
> change its name.
>=20
> The title is not something they care about.
>=20
> Brian
>=20
> > -----Original Message-----
> > From: Simon Pietro Romano [mailto:spromano@unina.it]
> > Sent: Monday, January 29, 2007 12:01 PM
> > To: Drage, Keith (Keith)
> > Cc: XCON
> > Subject: RE: [XCON] New drafts on Distributed Conferencing
> >=20
> > Hi Keith,
> >=20
> > did you read just the title? What if the filename were:
> >=20
> > "A framework to improve XCON scalability throguh focus replication"?
> >=20
> > Would this sound more politically correct?
> >=20
> > Cheers,
> >=20
> > Simon
> > --
> >                             _\\|//_
> >                             ( O-O )
> >    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
> >                     Simon Pietro Romano
> >               Universita' di Napoli Federico II
> >                  Computer Science Department
> >         Phone: +39 081 7683823 -- Fax: +39 081 7684219
> >                 e-mail: spromano@unina.it
> >=20
> >     <<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli
> >    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
> >                          oooO
> >    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
> >                           \ (    (   )
> >                            \_)    ) /
> >                                  (_/
> >=20
> >=20
> >=20
> >=20
> > Scrive "Drage, Keith (Keith)" <drage@alcatel-lucent.com>:
> >=20
> > > With these filenames I would expect rejection from the=20
> secretariat.
> > >
> > > I don't remember any discussion to open new WG milestones on this
> > subject,
> > > which means these cannot be XCON WG items.
> > >
> > > Regards
> > >
> > > Keith
> > >
> > > > -----Original Message-----
> > > > From: Simon Pietro Romano [mailto:spromano@unina.it]
> > > > Sent: 28 January 2007 11:45
> > > > To: XCON
> > > > Subject: [XCON] New drafts on Distributed Conferencing
> > > >
> > > > Dear all,
> > > >
> > > > we just submitted two new drafts on Distributed Conferencing.
> > > > You can find them
> > > > at:
> > > >
> > > > 1- "A Framework for Distributed COnferencing":
> > > >=20
> http://dcon.sourceforge.net/docs/draft-ietf-xcon-dcon-framework-00
> > > > .txt
> > > >
> > > > 2- "Requirements for the XCON-DCON Synchronization Protocol"
> > > > -->
> > > >=20
> http://dcon.sourceforge.net/docs/draft-ietf-xcon-dcon-xdsp-reqs-00
> > > > .txt
> > > >
> > > > We're looking forward to receiving your comments.
> > > >
> > > > Cheers,
> > > >
> > > > Simon
> > > > --
> > > >                             _\\|//_
> > > >                             ( O-O )
> > > >    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
> > > >                     Simon Pietro Romano
> > > >               Universita' di Napoli Federico II
> > > >                  Computer Science Department
> > > >         Phone: +39 081 7683823 -- Fax: +39 081 7684219
> > > >                 e-mail: spromano@unina.it
> > > >
> > > >     <<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli
> > > >    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
> > > >                          oooO
> > > >    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
> > > >                           \ (    (   )
> > > >                            \_)    ) /
> > > >                                  (_/
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ----------------------------------------------------------------
> > > > This message was sent using IMP, the Internet Messaging Program.
> > > >
> > > > _______________________________________________
> > > > XCON mailing list
> > > > XCON@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/xcon
> > > >
> > >
> >=20
> >=20
> > ----------------------------------------------------------------
> > This message was sent using IMP, the Internet Messaging Program.
> >=20
> > _______________________________________________
> > XCON mailing list
> > XCON@ietf.org
> > https://www1.ietf.org/mailman/listinfo/xcon
>=20
>=20

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Mon Jan 29 13:37:50 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBbNy-0005nx-FY; Mon, 29 Jan 2007 13:37:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBbNx-0005ns-QP
	for xcon@ietf.org; Mon, 29 Jan 2007 13:37:45 -0500
Received: from zcars04f.nortel.com ([47.129.242.57])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBbNw-0002kf-En
	for xcon@ietf.org; Mon, 29 Jan 2007 13:37:45 -0500
Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com
	[47.103.123.72])
	by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id
	l0TIbJb04133; Mon, 29 Jan 2007 13:37:19 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [XCON] I-D ACTION:draft-ietf-xcon-framework-07.txt
Date: Mon, 29 Jan 2007 12:37:15 -0600
Message-ID: <E3F9D87C63E2774390FE67C924EC99BB0AB3E057@zrc2hxm1.corp.nortel.com>
In-Reply-To: <E1H9Sag-00044M-6H@stiedprstage1.ietf.org>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [XCON] I-D ACTION:draft-ietf-xcon-framework-07.txt
Thread-Index: Acc/ME1HmIxG4mYwR0CVCFyqTHHg9AEo1cFg
From: "Mary Barnes" <mary.barnes@nortel.com>
To: <xcon@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Cc: "adam@estacado.net" <'adam@estacado.net'>, alan@sipstation.com
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

Hi all,

This update addresses the WGLC comments, with the changes summarized as
follows:

1) Section 4: Added definition for Conference User Identifier,
   including concept of a single user having multiple identifiers.

2) Section 9: Clarified text to indicate that details of message
   flows are illustrative and exact states, etc. will be defined by the
   detailed data model, etc.

3) Section 9.4.1: Clarified that "Alice" and "Bob" remain in roster
   of main conference while in sidebar.Clarified text that Bob must
   already be a user of the conferencing system for internal sidebar
   scenario.

4) Section 9.4.1/9.4.2: Clarified text in last paragraph to indicate
   that notifications may also go to the initial requestor.

5) Section 9.5: Clarified text to explicitly state that sidebar
   participants also receive the audio from the main conference.

6) Fixed Editorial nits including updating references to published
   RFC numbers and miscellaneous typos.


The document should now be ready for forwarding to the IESG.=20

Regards,
Mary


-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20
Sent: Tuesday, January 23, 2007 2:50 PM
To: i-d-announce@ietf.org
Cc: xcon@ietf.org
Subject: [XCON] I-D ACTION:draft-ietf-xcon-framework-07.txt


A New Internet-Draft is available from the on-line Internet-Drafts=20
directories.
This draft is a work item of the Centralized Conferencing Working Group
of the IETF.

	Title		: A Framework and Data Model for Centralized
Conferencing
	Author(s)	: M. Barnes, et al.
	Filename	: draft-ietf-xcon-framework-07.txt
	Pages		: 62
	Date		: 2007-1-23
=09
This document defines the framework for Centralized Conferencing.
   The framework allows participants using various call signaling
   protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in
   a centralized unicast conference.  The Centralized Conferencing
   Framework defines logical entities and naming conventions, along with
   a conferencing data model.  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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-07.txt

To remove yourself from the I-D Announcement list, send a message to=20
i-d-announce-request@ietf.org with the word unsubscribe in the body of=20
the message.=20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the=20
username "anonymous" and a password of your e-mail address. After=20
logging in, type "cd internet-drafts" and then=20
"get draft-ietf-xcon-framework-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-xcon-framework-07.txt".
=09
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Mon Jan 29 14:01:47 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBblD-0004qi-Bs; Mon, 29 Jan 2007 14:01:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBblB-0004qU-Kw
	for xcon@ietf.org; Mon, 29 Jan 2007 14:01:45 -0500
Received: from co300216-ier2.net.avaya.com ([198.152.13.103])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBbl9-0005ly-Gt
	for xcon@ietf.org; Mon, 29 Jan 2007 14:01:45 -0500
Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com
	[198.152.6.52])
	by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP
	id l0TJ1fT0009947
	for <xcon@ietf.org>; Mon, 29 Jan 2007 14:01:41 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [XCON] data-model-03 comments - non-runtime data
Date: Mon, 29 Jan 2007 14:01:41 -0500
Message-ID: <6900257941B31D4A954C71DEF805B9A20BEA0CDC@nj7460avexu2.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [XCON] data-model-03 comments - non-runtime data
Thread-Index: AcdBGsYvT3NlTJvURS20JkZ5989a/gCvPyhQ
From: "Braudes, Robert \(Bob\)" <braudes@avaya.com>
To: "Gonzalo Camarillo" <Gonzalo.Camarillo@ericsson.com>
X-Scanner: InterScan AntiVirus for Sendmail
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Cc: "Even, Roni" <roni.even@polycom.co.il>, XCON-IETF <xcon@ietf.org>
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

At this point it's probably easiest if I write something up, and we can
then decide which pieces should go into the base data model, which go
into extensions, and which are deemed out-of-scope.

Bob=20

-----Original Message-----
From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20
Sent: Friday, January 26, 2007 2:23 AM
To: Braudes, Robert (Bob)
Cc: Even, Roni; XCON-IETF
Subject: Re: [XCON] data-model-03 comments - non-runtime data

Hi,

I guess we could define all the CDR-related elements in an extension, as
opposed to the base data model.

Regarding usage data, could you provide us with a couple of examples of
the elements you would like to define so that we can discuss whether
they belong to the based data model or to an extension?

Thanks,

Gonzalo


Braudes, Robert (Bob) wrote:
> Hi Camarillo and Roni,
>=20
> 	Thanks for your comments.  I apologize for missing the iCal
reference=20
> in Section 3.3.1, and was thinking that this was only the time of the=20
> current instance rather than for a conference series.  My larger=20
> concerns are how to build an end-to-end conferencing system with this=20
> data model.  For example, how are the blueprints available on a=20
> conference server accessed or modified?  While there is a reference to

> CDRs in section 3.3, <conference-description, it is mentioned that the

> conference control protocol is used to access CDRs, but I'm not sure=20
> how this is accomplished if there are no CDRs in the data model. =20
> Similarly, usage data is often required by our Customers, but I don't=20
> see where this is included in the data model.  We could have a=20
> separate extension to this data model, and that was actually my first=20
> thought, but it was suggested that this should be included in the base

> model.  I am very willing to write up a proposed extension if this is=20
> the direction that the Working Group would like to take.
>=20
> Thanks,
>=20
> Bob
>=20
> -----Original Message-----
> From: Even, Roni [mailto:roni.even@polycom.co.il]
> Sent: Thursday, January 25, 2007 1:48 AM
> To: Gonzalo Camarillo; Braudes, Robert (Bob)
> Cc: XCON-IETF
> Subject: RE: [XCON] data-model-03 comments - non-runtime data
>=20
> Hi,
> I think that some of the items are covered. Also note that the data=20
> model is inline with the framework draft and the scenarios (RFC 4597)=20
> For scheduling we have iCAL component.
> New users for the conference can be defined by adding them to the list

> of participants.
> The conference object exists before the conference starts, during the=20
> conference tile and can be saved by the conferencing server as part of

> a CDR.
>=20
> I am not sure what you mean by missing elements
>=20
> Roni Even
>=20
>> -----Original Message-----
>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]
>> Sent: Thursday, January 25, 2007 8:06 AM
>> To: Braudes, Robert (Bob)
>> Cc: XCON-IETF
>> Subject: Re: [XCON] data-model-03 comments - non-runtime data
>>
>> Hi Bob,
>>
>> the data model will contain the elements needed by most basic=20
>> conferences. That is, the data model intends to be the maximum common

>> denominator of all conferences, plus maybe a few additions of=20
>> elements
>=20
>> used by many conferences (but not necessarily by all).
>>
>> Therefore, what we need to discuss is whether the stuff you have in=20
>> mind belongs to the data model itself or to an extension.
>>
>> Cheers,
>>
>> Gonzalo
>>
>>
>> Braudes, Robert (Bob) wrote:
>>> When reviewing the draft, I have a concern that the current data=20
>>> model is focused on the runtime aspects of conferencing, and doesn't
>=20
>>> include data needed for provisioning new users, accessing=20
>>> CDRs/IPDRs, scheduling one-time and recurring conferences, managing=20
>>> blueprints, or other pre- and post-conference activities.  Before=20
>>> making suggested changes to the document, I would like to hear from=20
>>> others as I am anticipating proposing a fairly large number of
> additions to the model.
>>> Thanks,
>>>
>>> Bob
>>>
>>> Bob Braudes | Consulting Member of the Technical Staff |=20
>>> Conferencing and Collaboration | Avaya | 150 Apollo Drive |=20
>>> Chelmsford, MA 01824 | W: +1 978 677 5031 M:
>>> +1 978 973 5199 | braudes@avaya.com
>>>
>>>
>>>
>>> --------------------------------------------------------------------
>>> ----
>>>
>>> _______________________________________________
>>> XCON mailing list
>>> XCON@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/xcon
>>
>> _______________________________________________
>> XCON mailing list
>> XCON@ietf.org
>> https://www1.ietf.org/mailman/listinfo/xcon
>=20


_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Mon Jan 29 16:56:36 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBeUH-0001C1-5x; Mon, 29 Jan 2007 16:56:29 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBeUF-0001Bu-Jv
	for xcon@ietf.org; Mon, 29 Jan 2007 16:56:27 -0500
Received: from webmail.unina.it ([192.132.34.212])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBeUC-0002JM-90
	for xcon@ietf.org; Mon, 29 Jan 2007 16:56:26 -0500
Received: from webmail.unina.it (localhost [127.0.0.1])
	by webmail.unina.it (8.12.11/8.12.11) with ESMTP id l0TLxgLB005989;
	Mon, 29 Jan 2007 22:59:42 +0100
Received: (from nobody@localhost)
	by webmail.unina.it (8.12.11/8.12.11/Submit) id l0TLxbgs005988;
	Mon, 29 Jan 2007 22:59:37 +0100
X-Authentication-Warning: webmail.unina.it: nobody set sender to
	spromano@unina.it using -f
Received: from host5-105-dynamic.7-87-r.retail.telecomitalia.it
	(host5-105-dynamic.7-87-r.retail.telecomitalia.it [87.7.105.5])
	by webmail.unina.it (IMP) with HTTP 
	for <spromano@192.132.34.41>; Mon, 29 Jan 2007 22:59:37 +0100
Message-ID: <1170107977.45be6e49c76b3@webmail.unina.it>
Date: Mon, 29 Jan 2007 22:59:37 +0100
From: Simon Pietro Romano <spromano@unina.it>
To: "Drage, Keith (Keith)" <drage@alcatel-lucent.com>
Subject: RE: [XCON] New drafts on Distributed Conferencing
References: <1170090083.45be2863a79e4@webmail.unina.it>
	<051901c743c7$8c3847c0$640fa8c0@cis.neustar.com>
	<5D1A7985295922448D5550C94DE29180BD3425@DEEXC1U01.de.lucent.com>
In-Reply-To: <5D1A7985295922448D5550C94DE29180BD3425@DEEXC1U01.de.lucent.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
User-Agent: Internet Messaging Program (IMP) 3.2.2
X-Originating-IP: 87.7.105.5
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by webmail.unina.it id
	l0TLxgLB005989
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9
Cc: XCON <xcon@ietf.org>
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

OK. Sorry for the misunderstanding about file names. I have to admit I wa=
s not
aware of this naming convention ;-).

Regards,

Simon


--=20
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department=20
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: spromano@unina.it

    <<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli=20
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/




Scrive "Drage, Keith (Keith)" <drage@alcatel-lucent.com>:

> Exactly.
>=20
> And the reason for copying the list was so that I could be corrected if=
 the
> discussion really had taken place.
>=20
> Having submitted an author draft, your next step is to persuade the IET=
F that
> this is an interesting problem to work on, either within XCON or using =
some
> other mechanism. The WG chairs should be able to advise you on good thi=
ngs to
> help this happen.
>=20
> Keith=20
>=20
> > -----Original Message-----
> > From: Brian Rosen [mailto:br@brianrosen.net]=20
> > Sent: 29 January 2007 17:05
> > To: 'Simon Pietro Romano'; Drage, Keith (Keith)
> > Cc: 'XCON'
> > Subject: RE: [XCON] New drafts on Distributed Conferencing
> >=20
> > I believe he was referring to the fact that you can't have a=20
> > file starting with draft-ietf-xcon unless it is already=20
> > accepted as a work group item.
> >=20
> > Since this is your own private draft, it has to have a=20
> > filename like draft-romano-xcon-dcon-xdsp-reqs-00
> >=20
> > The secretariat is unlikely to accept your draft until you=20
> > change its name.
> >=20
> > The title is not something they care about.
> >=20
> > Brian
> >=20
> > > -----Original Message-----
> > > From: Simon Pietro Romano [mailto:spromano@unina.it]
> > > Sent: Monday, January 29, 2007 12:01 PM
> > > To: Drage, Keith (Keith)
> > > Cc: XCON
> > > Subject: RE: [XCON] New drafts on Distributed Conferencing
> > >=20
> > > Hi Keith,
> > >=20
> > > did you read just the title? What if the filename were:
> > >=20
> > > "A framework to improve XCON scalability throguh focus replication"=
?
> > >=20
> > > Would this sound more politically correct?
> > >=20
> > > Cheers,
> > >=20
> > > Simon
> > > --
> > >                             _\\|//_
> > >                             ( O-O )
> > >    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
> > >                     Simon Pietro Romano
> > >               Universita' di Napoli Federico II
> > >                  Computer Science Department
> > >         Phone: +39 081 7683823 -- Fax: +39 081 7684219
> > >                 e-mail: spromano@unina.it
> > >=20
> > >     <<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli
> > >    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
> > >                          oooO
> > >    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
> > >                           \ (    (   )
> > >                            \_)    ) /
> > >                                  (_/
> > >=20
> > >=20
> > >=20
> > >=20
> > > Scrive "Drage, Keith (Keith)" <drage@alcatel-lucent.com>:
> > >=20
> > > > With these filenames I would expect rejection from the=20
> > secretariat.
> > > >
> > > > I don't remember any discussion to open new WG milestones on this
> > > subject,
> > > > which means these cannot be XCON WG items.
> > > >
> > > > Regards
> > > >
> > > > Keith
> > > >
> > > > > -----Original Message-----
> > > > > From: Simon Pietro Romano [mailto:spromano@unina.it]
> > > > > Sent: 28 January 2007 11:45
> > > > > To: XCON
> > > > > Subject: [XCON] New drafts on Distributed Conferencing
> > > > >
> > > > > Dear all,
> > > > >
> > > > > we just submitted two new drafts on Distributed Conferencing.
> > > > > You can find them
> > > > > at:
> > > > >
> > > > > 1- "A Framework for Distributed COnferencing":
> > > > >=20
> > http://dcon.sourceforge.net/docs/draft-ietf-xcon-dcon-framework-00
> > > > > .txt
> > > > >
> > > > > 2- "Requirements for the XCON-DCON Synchronization Protocol"
> > > > > -->
> > > > >=20
> > http://dcon.sourceforge.net/docs/draft-ietf-xcon-dcon-xdsp-reqs-00
> > > > > .txt
> > > > >
> > > > > We're looking forward to receiving your comments.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Simon
> > > > > --
> > > > >                             _\\|//_
> > > > >                             ( O-O )
> > > > >    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
> > > > >                     Simon Pietro Romano
> > > > >               Universita' di Napoli Federico II
> > > > >                  Computer Science Department
> > > > >         Phone: +39 081 7683823 -- Fax: +39 081 7684219
> > > > >                 e-mail: spromano@unina.it
> > > > >
> > > > >     <<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli
> > > > >    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
> > > > >                          oooO
> > > > >    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > >                           \ (    (   )
> > > > >                            \_)    ) /
> > > > >                                  (_/
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------=
-
> > > > > This message was sent using IMP, the Internet Messaging Program.
> > > > >
> > > > > _______________________________________________
> > > > > XCON mailing list
> > > > > XCON@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/xcon
> > > > >
> > > >
> > >=20
> > >=20
> > > ----------------------------------------------------------------
> > > This message was sent using IMP, the Internet Messaging Program.
> > >=20
> > > _______________________________________________
> > > XCON mailing list
> > > XCON@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/xcon
> >=20
> >=20
>=20


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Tue Jan 30 05:31:34 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBqGq-00072J-0Z; Tue, 30 Jan 2007 05:31:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBqGp-00072B-KT
	for xcon@ietf.org; Tue, 30 Jan 2007 05:31:23 -0500
Received: from mail.unina.it ([192.132.34.73])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBqGY-0006p0-Qe
	for xcon@ietf.org; Tue, 30 Jan 2007 05:31:23 -0500
Received: from [143.225.229.174] ([143.225.229.174])
	by mail.unina.it (8.13.7/8.13.7) with ESMTP id l0UBNQXS017836;
	Tue, 30 Jan 2007 12:23:26 +0100
Message-ID: <45BF1E21.6060003@libero.it>
Date: Tue, 30 Jan 2007 11:29:53 +0100
From: Lorenzo Miniero <rainmaker@libero.it>
User-Agent: Mozilla Thunderbird 1.5.0.9 (X11/20061219)
MIME-Version: 1.0
To: xcon@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-unina-it-MailScanner-Information: Please contact www.csi.unina.it for
	information
X-unina-it-MailScanner: Found to be clean
X-unina-it-MailScanner-SpamCheck: non spam, SpamAssassin (punteggio=0.017,
	necessario 6, autolearn=disabled, AWL 0.02)
X-unina-it-MailScanner-From: rainmaker@libero.it
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mail.unina.it id
	l0UBNQXS017836
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: 
Subject: [XCON] New drafts on Distributed Conferencing: filenames fixed
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org

Dear all,

we fixed the filenames issue regarding the drafts we recently published=20
on the distribution of XCON conferences.

You can find the renamed drafts at:

   1.

      "Requirements for Distributed Conferencing":
      http://dcon.sourceforge.net/docs/draft-unina-dcon-requirements-00.t=
xt

   2.

      "A Framework for Distributed Conferencing":
      http://dcon.sourceforge.net/docs/draft-unina-dcon-framework-00.txt

   3. "Requirements for the XCON-DCON Synchronization Protocol"
      http://dcon.sourceforge.net/docs/draft-unina-dcon-xdsp-reqs-00.txt


We're looking forward to receiving your comments and feedback.

Best regards,
Lorenzo

--=20
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Universit=E0 degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: lminiero@gmail.com


--=20
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.


_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon



From xcon-bounces@ietf.org Tue Jan 30 15:52:27 2007
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HBzxp-00053d-FS; Tue, 30 Jan 2007 15:52:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HBzxo-000522-7L
	for xcon@ietf.org; Tue, 30 Jan 2007 15:52:24 -0500
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBzxm-00076p-Ln
	for xcon@ietf.org; Tue, 30 Jan 2007 15:52:24 -0500
Received: from [172.17.2.61] (vicuna-alt.estacado.net [75.53.54.121])
	(authenticated bits=0)
	by nostrum.com (8.13.8/8.13.8) with ESMTP id l0UKqLfx096816
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 30 Jan 2007 14:52:22 -0600 (CST)
	(envelope-from adam@nostrum.com)
Message-ID: <45BFB003.9020508@nostrum.com>
Date: Tue, 30 Jan 2007 14:52:19 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
MIME-Version: 1.0
To: XCON-IETF <xcon@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227
Cc: Alan Johnston <alan@sipstation.com>
Subject: [XCON] Publication Request: draft-ietf-xcon-bfcp-connection-03
X-BeenThere: xcon@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Centralized Conferencing <xcon.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:xcon@ietf.org>
List-Help: <mailto:xcon-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/xcon>,
	<mailto:xcon-request@ietf.org?subject=subscribe>
Errors-To: xcon-bounces@ietf.org


The XCON Working Group chairs have requested publication of the document 
draft-ietf-xcon-bfcp-connection-03. The Document Shepherd Write-Up 
follows. (For details regarding Document Shepherd procedures, please see 
draft-ietf-proto-wgchair-doc-shepherding-08).

/a

--------

   (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Adam Roach <adam@nostrum.com> has personally reviewed this version
of the  document, and beleives it is ready to be forwarded to the
IESG for publication.


   (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document has gone through a working group last call, which ended
last November. It has been completely reveiewed by at least one key
contributor to the XCON working group. Additionally, the RAI-area
security advisor has provided specific and detailed comments on
improvments to the document, which have been incorporated. Key
points of the document were discussed in person at the 66th IETF
meeting. The working group chairs brought specific points of consensus
from this meeting to the mailing list for validation.

Compared to other working group documents, the overall discussion
activity surrounding this document has been quite light. This is
not surprising in light of its relatively small size, and the
uncontroversial nature of its contents. Consequently, the shepherd
has no reservations progressing the document, despite the relatively
low activity surrounding it.

   (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

The only components of this document that lie outside the domain
of expertise for the XCON working group relate to security, and
the shepherd is satisfied that the security review of this document
is adequate.

   (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.

The shepherd is comfortable with the contents of the document. The working
group has not expressed strong opinions either for or against publication
of the document. Nevertheless, the mechanism described in this document
is a useful specification that completes RFC 4582, and allows its use
outside the context of conventional XCON conferences.

   (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

The document represents the position of select key contributors to the
working group, with limited interest from others.


   (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

There has been no discontent -- extreme or otherwise -- expressed
regarding this document.


   (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

The shepherd has manually verified compliance with the ID nits
list. No additional formal reviews are necessary.

   (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

All normatively cited RFCs are Proposed Standard, except for
the following two:

  2119 - BCP
  2898 - Informational

   (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggested a
          reasonable name for the new registry?  See
          [I-D.narten-iana-considerations-rfc2434bis].  If the document
          describes an Expert Review process has Shepherd conferred with
          the Responsible Area Director so that the IESG can appoint the
          needed Expert during the IESG Evaluation?

The document requires no actions of IANA, and the IANA Considerations
section accurately reflects this fact.

   (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

There are no formal declarations in this document.

   (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Writeup?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

  Technical Summary

    This document specifies how a Binary Floor Control
    Protocol (BFCP) client establishes a connection to a
    BFCP floor control server outside the context of an
    offer/answer exchange.  Client and server authentication
    are based on Transport Layer Security (TLS).

  Working Group Summary

     This document is a product of the XCON working group.
     Its contents have been uncontroversial in working group
     discussions.

  Document Quality

     Eric Rescorla reviewed the document from a security
     perspective. Based on his feedback, the client
     authentication mechanism was changed from one based
     loosely on HTTP digest authentication to the use of
     TLS with pre-shared keys.

     Adam Roach has reviewed the document for quality.

  Personnel

     Adam Roach is the Document Shepherd for this document.
     Cullen Jennings is the responsible Area Director.

  RFC Editor Note

    In Section 3, paragraph 5, please correct as follows:

    OLD:
      This will guarantee optimal routing.

    NEW:
      This will result in the selection of a preferred
      destination address.

    --

    In Section 5.1, paragraph 4, please correct as follows:

    OLD:
     If more than one identity of a given type is present
     in the certificate (e.g., more than one dNSName name,
     a match in any one of the set is considered acceptable).

    NEW:
     If more than one identity of a given type is present
     in the certificate (e.g., more than one dNSName name),
     a match in any one of the set is considered acceptable.

    --

    Normative References: Please replace RFC 2459 with RFC 3280.


_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon