From xcon-bounces@ietf.org Mon Apr 03 04:50:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQKlz-0000xN-BO; Mon, 03 Apr 2006 04:50:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FQKlx-0000jl-MJ
	for xcon@ietf.org; Mon, 03 Apr 2006 04:50:53 -0400
Received: from prix.tandberg.no ([194.196.35.10])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQKlw-0006r9-7a
	for xcon@ietf.org; Mon, 03 Apr 2006 04:50:53 -0400
Received: from 47mail.eu.tandberg.int (47mail.eu.tandberg.int [10.0.0.25])
	by prix.tandberg.no (8.12.10/8.12.10) with ESMTP id k338opOD023910
	for <xcon@ietf.org>; Mon, 3 Apr 2006 10:50:51 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 3 Apr 2006 10:50:50 +0200
Message-ID: <01C679F7AECF2B47B489F735B7EE49005BB5AC@47mail.eu.tandberg.int>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: How to distribute a list of all participants?
Thread-Index: AcZRmh1VMHsf2eroSECiQyIxY47qPgAF1aUQAAAMe5AAAbnv8AAAaqAAAFfUi+AA+H4OMA==
From: "Trond G. Andersen" <trond.andersen@tandberg.net>
To: "XCON-IETF" <xcon@ietf.org>
X-Scanned-By: MIMEDefang 2.45
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Subject: [XCON] How to distribute a list of all participants?
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="===============1912991940=="
Errors-To: xcon-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1912991940==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C656FB.B566FE94"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C656FB.B566FE94
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi.
=20
I am trying to figure out how to get a list of all participants in an
ongoing conference within the XCON framework.  I don ' t see how BFCP
would be able to transer a list of userid's (sitelist) , so how will we
do it?
=20
=20
Thanks,
trond

------_=_NextPart_001_01C656FB.B566FE94
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.2802" name=3DGENERATOR>
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 72.0pt 90.0pt 72.0pt =
90.0pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial
}
SPAN.EmailStyle19 {
	COLOR: navy; FONT-FAMILY: Arial
}
SPAN.EmailStyle20 {
	COLOR: navy; FONT-FAMILY: Arial
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D612203212-31032006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D612203212-31032006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D612203212-31032006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I am trying to figure out how to get a list of =
all=20
participants in an ongoing conference within the XCON framework.&nbsp; I =

don<SPAN class=3D246254908-03042006>&nbsp;'&nbsp;</SPAN>t see how BFCP =
would be=20
able to transer a list of userid's<SPAN=20
class=3D246254908-03042006>&nbsp;(sitelist)&nbsp;</SPAN>, so how will we =
do=20
it?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D612203212-31032006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D612203212-31032006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D612203212-31032006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D612203212-31032006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>trond</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C656FB.B566FE94--


--===============1912991940==
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

--===============1912991940==--




From xcon-bounces@ietf.org Mon Apr 03 04:54:56 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQKps-0002PM-4o; Mon, 03 Apr 2006 04:54:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FQKpr-0002PH-Ku
	for xcon@ietf.org; Mon, 03 Apr 2006 04:54:55 -0400
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQKpp-0006xX-OQ
	for xcon@ietf.org; Mon, 03 Apr 2006 04:54:55 -0400
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2F54EFA9; 
	Mon,  3 Apr 2006 10:54:53 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 3 Apr 2006 10:54:42 +0200
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 3 Apr 2006 10:54:35 +0200
Received: from [131.160.37.58] (EGUUG000L5C5TEU.lmf.ericsson.se
	[131.160.37.58])
	by mail.lmf.ericsson.se (Postfix) with ESMTP id B3C6B2973;
	Mon,  3 Apr 2006 11:54:35 +0300 (EEST)
Message-ID: <4430E2CB.3050409@ericsson.com>
Date: Mon, 03 Apr 2006 11:54:35 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Adam Roach <adam@nostrum.com>
Subject: Re: [XCON] Minutes Posted
References: <44241C21.8070804@nostrum.com>
In-Reply-To: <44241C21.8070804@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 Apr 2006 08:54:35.0514 (UTC)
	FILETIME=[3B6945A0:01C656FC]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: 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 Adam,

could you mention in the minutes that the BFCP connection draft was 
supposed to be presented by that we ran out of time?

Thanks,

Gonzalo

Adam Roach wrote:
> [as chair]
> 
> The minutes from the ad-hoc meeting are now posted on the IETF materials
> page:
> 
> https://datatracker.ietf.org/public/proceeding_interim.cgi?meeting_num=65
> 
> /a
> 
> _______________________________________________
> XCON mailing list
> XCON@ietf.org
> https://www1.ietf.org/mailman/listinfo/xcon
> 

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

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



From xcon-bounces@ietf.org Mon Apr 03 04:56:52 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQKrk-00051E-2E; Mon, 03 Apr 2006 04:56:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FQKri-0004w4-KW
	for xcon@ietf.org; Mon, 03 Apr 2006 04:56:50 -0400
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 1FQKrh-00072e-6z
	for xcon@ietf.org; Mon, 03 Apr 2006 04:56:50 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [XCON] How to distribute a list of all participants?
Date: Mon, 3 Apr 2006 11:56:46 +0300
Message-ID: <144ED8561CE90C41A3E5908EDECE315C03632AC3@IsrExch01.israel.polycom.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [XCON] How to distribute a list of all participants?
Thread-Index: AcZRmh1VMHsf2eroSECiQyIxY47qPgAF1aUQAAAMe5AAAbnv8AAAaqAAAFfUi+AA+H4OMAAAJAiw
From: "Even, Roni" <roni.even@polycom.co.il>
To: "Trond G. Andersen" <trond.andersen@tandberg.net>,
	"XCON-IETF" <xcon@ietf.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985
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>
Content-Type: multipart/mixed; boundary="===============0536904031=="
Errors-To: xcon-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0536904031==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C656FC.89D4CDA8"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C656FC.89D4CDA8
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,
To get the p[articipant list you need to subscribe to the conference
event package
=20
http://tools.ietf.org/wg/sipping/draft-ietf-sipping-conference-package/d
raft-ietf-sipping-conference-package-12.txt
=20
Roni Even

________________________________

From: Trond G. Andersen [mailto:trond.andersen@tandberg.net]=20
Sent: Monday, April 03, 2006 11:51 AM
To: XCON-IETF
Subject: [XCON] How to distribute a list of all participants?


Hi.
=20
I am trying to figure out how to get a list of all participants in an
ongoing conference within the XCON framework.  I don ' t see how BFCP
would be able to transer a list of userid's (sitelist) , so how will we
do it?
=20
=20
Thanks,
trond

------_=_NextPart_001_01C656FC.89D4CDA8
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.2802" name=3DGENERATOR>
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 72.0pt 90.0pt 72.0pt =
90.0pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial
}
SPAN.EmailStyle19 {
	COLOR: navy; FONT-FAMILY: Arial
}
SPAN.EmailStyle20 {
	COLOR: navy; FONT-FAMILY: Arial
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV><SPAN class=3D033275308-03042006><FONT face=3DArial color=3D#0000ff =

size=3D2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=3D033275308-03042006><FONT face=3DArial color=3D#0000ff =
size=3D2>To get=20
the p[articipant list you need to subscribe to the conference event=20
package</FONT></SPAN></DIV>
<DIV><SPAN class=3D033275308-03042006><FONT face=3DArial color=3D#0000ff =

size=3D2>&nbsp;<A=20
href=3D"http://tools.ietf.org/wg/sipping/draft-ietf-sipping-conference-pa=
ckage/draft-ietf-sipping-conference-package-12.txt">http://tools.ietf.org=
/wg/sipping/draft-ietf-sipping-conference-package/draft-ietf-sipping-conf=
erence-package-12.txt</A></FONT></SPAN></DIV>
<DIV><SPAN class=3D033275308-03042006><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D033275308-03042006><FONT face=3DArial color=3D#0000ff =
size=3D2>Roni=20
Even</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Trond G. Andersen=20
[mailto:trond.andersen@tandberg.net] <BR><B>Sent:</B> Monday, April 03, =
2006=20
11:51 AM<BR><B>To:</B> XCON-IETF<BR><B>Subject:</B> [XCON] How to =
distribute a=20
list of all participants?<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D612203212-31032006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Hi.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D612203212-31032006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D612203212-31032006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I am trying to figure out how to get a list of =
all=20
participants in an ongoing conference within the XCON framework.&nbsp; I =

don<SPAN class=3D246254908-03042006>&nbsp;'&nbsp;</SPAN>t see how BFCP =
would be=20
able to transer a list of userid's<SPAN=20
class=3D246254908-03042006>&nbsp;(sitelist)&nbsp;</SPAN>, so how will we =
do=20
it?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D612203212-31032006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D612203212-31032006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D612203212-31032006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D612203212-31032006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>trond</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C656FC.89D4CDA8--


--===============0536904031==
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

--===============0536904031==--




From xcon-bounces@ietf.org Mon Apr 03 05:02:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FQKxL-00007h-TL; Mon, 03 Apr 2006 05:02:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FQKxL-00007c-LH
	for xcon@ietf.org; Mon, 03 Apr 2006 05:02:39 -0400
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQKxK-0007Jv-6U
	for xcon@ietf.org; Mon, 03 Apr 2006 05:02:39 -0400
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	24B4E4F0001
	for <xcon@ietf.org>; Mon,  3 Apr 2006 10:59:32 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 3 Apr 2006 10:59:31 +0200
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 3 Apr 2006 10:59:31 +0200
Received: from [131.160.37.58] (EGUUG000L5C5TEU.lmf.ericsson.se
	[131.160.37.58])
	by mail.lmf.ericsson.se (Postfix) with ESMTP id 6999C2973
	for <xcon@ietf.org>; Mon,  3 Apr 2006 11:59:31 +0300 (EEST)
Message-ID: <4430E3F3.1000609@ericsson.com>
Date: Mon, 03 Apr 2006 11:59:31 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
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: 03 Apr 2006 08:59:31.0161 (UTC)
	FILETIME=[EBA16C90:01C656FC]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
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,

we did not have time to present the BFCP connection draft during our 
session in Dallas. In any case, you can download the slides I intended 
to show from:
http://www3.ietf.org/proceedings/06mar/slides/xcon-4.ppt

I am interested in getting feedback on the open issue below, on slide 10th:

When a client gets the transport address of the server to perform an 
active TCP open:
o Do we allow FQDNs?
o If so, which DNS procedures do we define? SRV, A, AAAA...?

Thanks,

Gonzalo

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



From xcon-bounces@ietf.org Wed Apr 05 19:46:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FRHhM-0005SL-82; Wed, 05 Apr 2006 19:46:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FRHhL-0005SB-5A
	for xcon@ietf.org; Wed, 05 Apr 2006 19:46:03 -0400
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRHhJ-0003B8-S9
	for xcon@ietf.org; Wed, 05 Apr 2006 19:46:03 -0400
Received: from [172.17.2.251] (dsl001-129-070.dfw1.dsl.speakeasy.net
	[72.1.129.70]) (authenticated bits=0)
	by nostrum.com (8.13.4/8.13.4) with ESMTP id k35Njwqr009362
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <xcon@ietf.org>; Wed, 5 Apr 2006 18:46:00 -0500 (CDT)
	(envelope-from adam@nostrum.com)
Message-ID: <443456B0.9000209@nostrum.com>
Date: Wed, 05 Apr 2006 18:45:52 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: xcon@ietf.org
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 72.1.129.70 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Subject: [XCON] XCON Protocol Operations discussion
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

[as chair]

At the ad-hoc meeting in Dallas, the chairs solicited a group of
volunteers to actively work on an internet-draft to define the protocol
operations (but not the protocol itself) for conference manipulation.
The document will be brought to the working group as an individual
contribution.

This message is intended to allow anyone who was not present at that
meeting to volunteer to assist in creating this document. If you would
like to help out, please subscribe to the following mailing list:

http://www.nostrum.com/mailman/listinfo/xcon-ops

Note that anyone joining the list will be expected to participate in
weekly conference calls, and will be assigned specific work items to
complete. Do not join if you don't have the time to actively work on the
document.

Thanks.

/a

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



From xcon-bounces@ietf.org Sun Apr 09 13:39:23 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FSdsc-0006AC-Pe; Sun, 09 Apr 2006 13:39:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpR9-0007lj-HN
	for xcon@ietf.org; Tue, 21 Mar 2006 17:34:47 -0500
Received: from oak.neustar.com ([209.173.53.70])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLpR8-0007ak-CC
	for xcon@ietf.org; Tue, 21 Mar 2006 17:34:47 -0500
Received: from stntsmtp1.cis.neustar.com (smartexch.neustar.com [10.31.13.79])
	by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k2LMYkBW005450
	for <xcon@ietf.org>; Tue, 21 Mar 2006 22:34:46 GMT
Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by
	stntsmtp1.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830);
	Tue, 21 Mar 2006 17:34:45 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 21 Mar 2006 17:34:47 -0500
Message-ID: <ED0887AEB595F74DB74934F4C37C08DC074287D5@stntexch04.cis.neustar.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Verbs and Nouns
Thread-Index: AcZNN6jn0vEpPIr3TmqG6N3zitDVVQ==
From: "Rosen, Brian" <Brian.Rosen@neustar.biz>
To: <xcon@ietf.org>
X-OriginalArrivalTime: 21 Mar 2006 22:34:46.0117 (UTC)
	FILETIME=[A7D8A150:01C64D37]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
X-Mailman-Approved-At: Sun, 09 Apr 2006 13:39:16 -0400
Subject: [XCON] Verbs and Nouns
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="===============0404568534=="
Errors-To: xcon-bounces@ietf.org

--===============0404568534==
Content-class: urn:content-classes:message
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

SSB0aGluayB0aGUgcHVycG9zZSBvZiB0aGUgQm9GIGlzIHRvIGRlY2lkZSBvbiB0aGUgdmVyYnMg
YW5kIG5vdW5zLiAgTXkgbGlzdCBpczoNCg0KVmVyYg0KICBDcmVhdGUvRGVsZXRlIEl0ZW0NCiAg
ICAgTm91bnMNCiAgICAgICBDb25mZXJlbmNlDQogICAgICAgU2lkZWJhcg0KCSA/Rmxvb3I/DQoN
CiAgU2V0L0dldCBWYWx1ZSANCiAgICAgTm91bnMNCgkgQ29uZlN0YXRlDQoJIE1lZGlhUG9saWN5
DQoJIFNlY3VyaXR5UG9saWN5DQoJID9GbG9vciBDb250cm9sIFBvbGljeT8NCiAgICAgICBDb250
cm9scw0KCQ0KICBBZGQvRGVsZXRlIG1lbWJlciBvZiBsaXN0DQogICAgICBOb3Vucw0KCSAgRGlh
bCBPdXQNCgkgIFJlZmVyDQoJICBBbGxvd2VkIFBhcnRpY2lwYW50cw0KCSAgQWxsb3dlZCBGbG9v
ciBIb2xkZXJzDQoJICBBbGxvd2VkIEZsb29yIE1vZGVyYXRvcnMNCgkgIFNpZGViYXINCg0KSXTi
gJlzIGEgc3RhcnQg4pi6Og0KIA0KDQoNCg==


--===============0404568534==
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

--===============0404568534==--



From xcon-bounces@ietf.org Mon Apr 10 22:28:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FT8bs-0002ws-Fm; Mon, 10 Apr 2006 22:28:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FT8bs-0002wn-3u
	for xcon@ietf.org; Mon, 10 Apr 2006 22:28:04 -0400
Received: from serrano.cc.columbia.edu ([128.59.29.6])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FT8bq-00021c-TQ
	for xcon@ietf.org; Mon, 10 Apr 2006 22:28:04 -0400
Received: from [192.168.0.41] (pool-138-89-69-211.mad.east.verizon.net
	[138.89.69.211]) (user=hgs10 mech=PLAIN bits=0)
	by serrano.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k3B2Rxh8013171
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
	Mon, 10 Apr 2006 22:28:00 -0400 (EDT)
In-Reply-To: <ED0887AEB595F74DB74934F4C37C08DC074287D5@stntexch04.cis.neustar.com>
References: <ED0887AEB595F74DB74934F4C37C08DC074287D5@stntexch04.cis.neustar.com>
Mime-Version: 1.0 (Apple Message framework v746.3)
Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed
Message-Id: <A2C5FD22-79E6-4265-B3BF-D824ECDFEA48@cs.columbia.edu>
Content-Transfer-Encoding: quoted-printable
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [XCON] Verbs and Nouns
Date: Mon, 10 Apr 2006 22:28:22 -0400
To: "Rosen, Brian" <Brian.Rosen@neustar.biz>
X-Mailer: Apple Mail (2.746.3)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9
Cc: 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 suspect many of these would have to be somewhat finer-grained, such =20=

as MediaPolicy, unless you only want to allow replacing the whole =20
policy at once.

On Mar 21, 2006, at 5:34 PM, Rosen, Brian wrote:

> I think the purpose of the BoF is to decide on the verbs and =20
> nouns.  My list is:
>
> Verb
>   Create/Delete Item
>      Nouns
>        Conference
>        Sidebar
> 	 ?Floor?
>
>   Set/Get Value
>      Nouns
> 	 ConfState
> 	 MediaPolicy
> 	 SecurityPolicy
> 	 ?Floor Control Policy?
>        Controls
> =09
>   Add/Delete member of list
>       Nouns
> 	  Dial Out
> 	  Refer
> 	  Allowed Participants
> 	  Allowed Floor Holders
> 	  Allowed Floor Moderators
> 	  Sidebar
>
> It=E2=80=99s a start =E2=98=BA:
>
>
>
> _______________________________________________
> 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 Apr 12 02:33:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FTYv1-00071O-8u; Wed, 12 Apr 2006 02:33:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FTYuz-00070J-Gm
	for xcon@ietf.org; Wed, 12 Apr 2006 02:33:33 -0400
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTYuw-0000Sy-MB
	for xcon@ietf.org; Wed, 12 Apr 2006 02:33:33 -0400
Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id
	249354F0039
	for <xcon@ietf.org>; Wed, 12 Apr 2006 08:33:30 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 12 Apr 2006 08:33:29 +0200
Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 12 Apr 2006 08:33:29 +0200
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
Date: Wed, 12 Apr 2006 08:33:28 +0200
Message-ID: <A91F30A632473A47B40C18D2B107CA6F024C9E55@esealmw105.eemea.ericsson.se>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New version of the data model draft
thread-index: AcYAbz2Ce/P5lmxiEdq0TwARJEEJ/AAEskTwEE1h7pAHEIonoA==
From: "Oscar Novo \(JO/LMF\)" <oscar.novo@ericsson.com>
To: <xcon@ietf.org>
X-OriginalArrivalTime: 12 Apr 2006 06:33:29.0234 (UTC)
	FILETIME=[02D53720:01C65DFB]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Subject: [XCON] New version of the data model 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

Hello,

Today, I've submitted the new version of the "A Common Conference
Information Data Model for Centralized Conferencing" draft. Until it
appears in the archives, you can fetch it from:

http://users.piuha.net/gonzalo/temp/draft-ietf-xcon-common-data-model-00
.txt

Here's an overall summary of the changes:

- The policy information of the CPCP drafts is added to this document
(thanks Hisham Khartabil, Petri Koskelainen, and Aki Niemi to let me do
it).
- Definition of new elements for the PSTN, H.320, and H.323 protocols.=20
- Additional elements added.=20
- Modification of the handling of times in the data model as we agreed
in IETF-65.
- The XML schema is now validate.

I will appreciate your comments!

Kind Regards,

Oscar Novo

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



From xcon-bounces@ietf.org Mon Apr 17 14:23:18 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FVYNT-0004rb-I5; Mon, 17 Apr 2006 14:23:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FTD6T-0001uR-GQ; Tue, 11 Apr 2006 03:15:57 -0400
Received: from mail5.audiocodes.com ([212.25.125.21] helo=imss.audiocodes.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FTD6O-0003ue-Ty; Tue, 11 Apr 2006 03:15:57 -0400
Received: from aclmsg.corp.audiocodes.com ([10.1.0.8]) by imss with InterScan
	Messaging Security Suite; Tue, 11 Apr 2006 10:18:39 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 11 Apr 2006 10:15:17 +0300
Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD602018AB7@aclmsg.corp.audiocodes.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Video Transcoding using SIP & SDP
Thread-Index: AcZdN6+fI6Zyomf2QtulmbGVHUUBJA==
From: "Osher Hmelnizky" <Osher.Hmelnizky@audiocodes.com>
To: <mmusic@ietf.org>,
	<xcon@ietf.org>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
X-Mailman-Approved-At: Mon, 17 Apr 2006 14:23:10 -0400
Cc: Sharone Aloni <Sharone.Aloni@audiocodes.com>,
	Oren Kudovitzky <Orenku@audiocodes.com>
Subject: [XCON] Video Transcoding using SIP & SDP
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="===============0804643545=="
Errors-To: xcon-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0804643545==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C65D37.CE6D420B"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C65D37.CE6D420B
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Hello, is it any work in progress regarding Video transcoding services
using SIP and SDP.

I'm looking something like RFC 4117 for video.

=20

Thanks in advance

=20

Osher

=20


------_=_NextPart_001_01C65D37.CE6D420B
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hello, is it any work in progress regarding Video
transcoding services using SIP and SDP.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I&#8217;m looking something like RFC =
</span></font>4117 for
video.<o:p></o:p></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks in advance<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Osher<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C65D37.CE6D420B--


--===============0804643545==
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

--===============0804643545==--




From xcon-bounces@ietf.org Fri Apr 21 09:35:48 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FWvnX-0005Zl-DP; Fri, 21 Apr 2006 09:35:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FWvnV-0005ZV-Bs
	for xcon@ietf.org; Fri, 21 Apr 2006 09:35:45 -0400
Received: from mailgw3.ericsson.se ([193.180.251.60])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWvnS-0007uC-5w
	for xcon@ietf.org; Fri, 21 Apr 2006 09:35:45 -0400
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121])
	by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 882C68EC; 
	Fri, 21 Apr 2006 15:35:41 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 21 Apr 2006 15:35:40 +0200
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 21 Apr 2006 15:35:40 +0200
Received: from [131.160.37.58] (EGUUG000L5C5TEU.lmf.ericsson.se
	[131.160.37.58])
	by mail.lmf.ericsson.se (Postfix) with ESMTP id BF438236B;
	Fri, 21 Apr 2006 16:35:40 +0300 (EEST)
Message-ID: <4448DFAC.9080009@ericsson.com>
Date: Fri, 21 Apr 2006 16:35:40 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
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: 21 Apr 2006 13:35:40.0528 (UTC)
	FILETIME=[7B2DAF00:01C66548]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Cc: alan@sipstation.com, Keith Drage <drage@lucent.com>,
	Adam Roach <adam@nostrum.com>, Joerg Ott <jo@netlab.hut.fi>
Subject: [XCON] Proposed small fixes to BFCP
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,

while implementing our BFCP stack (the 'running code' part of the 
protocol), we have discovered a couple of relatively minor bugs in the 
BFCP spec that need to be fixed. They are probably too big to be fixed 
thru RFC editor notes. My suggestion would be to remove the draft from 
the queue, perform the changes I propose below, and send it back to the 
queue. Opinions?


Section 5.3.9 defines the ChairAction message. That message can contain 
several floors (which belong to the same floor request operation) but 
can only provide a single queue position (within the REQUEST-STATUS 
attribute) for all of them. We need to be able to provide different 
queue positions for different floors (e.g., second for floor 1 and third 
for floor 2). In order to do this, we need to define a new grouped 
attribute called FLOOR-REQUEST-STATUS whose definition would be the 
following:

Attribute header:

      0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |x x x x x x x|M|    Length     |           Floor ID            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Attribute ABNF:

  FLOOR-REQUEST-STATUS =   (FLOOR-REQUEST-STATUS-HEADER)
                           (REQUEST-STATUS)
                           [STATUS-INFO]
                          *[EXTENSION-ATTRIBUTE]

Now, the already existing FLOOR-REQUEST-INFORMATION grouped attribute 
would carry '1*(FLOOR-REQUEST-STATUS)' instead of '1*(FLOOR-ID)'

The same for the already existing ChairAction message.


Additionally, we would define a new grouped attribute called 
OVERALL-REQUEST-STATUS, whose definition would be almost identical to 
the FLOOR-REQUEST-STATUS attribute. The only difference is that this one 
would carry a Floor Request ID instead of a Floor ID. This attribute 
would be used within the FLOOR-REQUEST-INFORMATION attribute, whose ABNF 
would become:

OLD:

    FLOOR-REQUEST-INFORMATION =   (FLOOR-REQUEST-INFORMATION-HEADER)
                                  (REQUEST-STATUS)              <--
                                1*(FLOOR-ID)                    <--
                                  [BENEFICIARY-INFORMATION]
                                  [REQUESTED-BY-INFORMATION]
                                  [PRIORITY]
                                  [PARTICIPANT-PROVIDED-INFO]
                                  [STATUS-INFO]                 <--
                                 *[EXTENSION-ATTRIBUTE]

NEW:

    FLOOR-REQUEST-INFORMATION =   (FLOOR-REQUEST-INFORMATION-HEADER)
                                  (OVERALL-REQUEST-STATUS)
                                1*(FLOOR-REQUEST-STATUS)
                                  [BENEFICIARY-INFORMATION]
                                  [REQUESTED-BY-INFORMATION]
                                  [PRIORITY]
                                  [PARTICIPANT-PROVIDED-INFO]
                                 *[EXTENSION-ATTRIBUTE]



Then, we would need to add a brief discussion on queues, indicating that 
the queue positions in the OVERALL-REQUEST-STATUS attribute refer to 
positions in a global queue for floor requests and that queue positions 
in the FLOOR-REQUEST-STATUS attribute refer to positions in a queue for 
floor requests for a particular floor. Of course, implementations are 
free to implement (or provide information about) one, both, or none of 
these queue types.

The ChairAction message would become:

OLD:

    ChairAction  =   (COMMON-HEADER)
                   1*(FLOOR-ID)             <--
                     (FLOOR-REQUEST-ID)
                     (REQUEST-STATUS)       <--
                     [STATUS-INFO]
                    *[EXTENSION-ATTRIBUTE]

NEW:

    ChairAction  =   (COMMON-HEADER)
                   1*(FLOOR-REQUEST-STATUS)
                     (FLOOR-REQUEST-ID)
                     [STATUS-INFO]
                    *[EXTENSION-ATTRIBUTE]


A different issue (more easily fixable than the issue above) is that the 
FloorRequest and the FloorQuery messages should carry 1*(FLOOR-ID) 
instead of *(FLOOR-ID).

Cheers,

Gonzalo

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



From xcon-bounces@ietf.org Fri Apr 21 11:26:02 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FWxWD-0002qo-L3; Fri, 21 Apr 2006 11:26:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FWxWB-0002qL-UF
	for xcon@ietf.org; Fri, 21 Apr 2006 11:25:59 -0400
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 1FWxWB-0006bd-Bo
	for xcon@ietf.org; Fri, 21 Apr 2006 11:25:59 -0400
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] Proposed small fixes to BFCP
Date: Fri, 21 Apr 2006 18:25:56 +0300
Message-ID: <144ED8561CE90C41A3E5908EDECE315C036F3834@IsrExch01.israel.polycom.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [XCON] Proposed small fixes to BFCP
Thread-Index: AcZlSI2MlKst4yslQCSAXh6oBHPH5AADi2Uw
From: "Even, Roni" <roni.even@polycom.co.il>
To: "Gonzalo Camarillo" <Gonzalo.Camarillo@ericsson.com>,
	"XCON" <xcon@ietf.org>
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
Cc: Adam Roach <adam@nostrum.com>, Keith Drage <drage@lucent.com>,
	alan@sipstation.com, Joerg Ott <jo@netlab.hut.fi>
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 guys,
I may open here a can of worms, but when looking at an implementation =
that includes BFCP as described in =
http://www.ietf.org/internet-drafts/draft-even-xcon-pnc-01.txt, we =
encountered the issue of NAT traversal. The pnc draft addresses =
multipoint cases but may also be used in a point to point case where one =
of the endpoints is the BFCP server. Since BFCP is only defined for TCP =
we feel that there is currently a lack of support for TCP based NAT =
traversal solutions. Maybe we can consider allowing BFCP over UDP.
Thanks
Roni Even=20

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]
> Sent: Friday, April 21, 2006 4:36 PM
> To: XCON
> Cc: alan@sipstation.com; Keith Drage; Adam Roach; Joerg Ott
> Subject: [XCON] Proposed small fixes to BFCP
>=20
> Folks,
>=20
> while implementing our BFCP stack (the 'running code' part of the
> protocol), we have discovered a couple of relatively minor bugs in the
> BFCP spec that need to be fixed. They are probably too big to be fixed
> thru RFC editor notes. My suggestion would be to remove the draft from
> the queue, perform the changes I propose below, and send it back to =
the
> queue. Opinions?
>=20
>=20
> Section 5.3.9 defines the ChairAction message. That message can =
contain
> several floors (which belong to the same floor request operation) but
> can only provide a single queue position (within the REQUEST-STATUS
> attribute) for all of them. We need to be able to provide different
> queue positions for different floors (e.g., second for floor 1 and =
third
> for floor 2). In order to do this, we need to define a new grouped
> attribute called FLOOR-REQUEST-STATUS whose definition would be the
> following:
>=20
> Attribute header:
>=20
>       0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |x x x x x x x|M|    Length     |           Floor ID            =
|
>       =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
> Attribute ABNF:
>=20
>   FLOOR-REQUEST-STATUS =3D   (FLOOR-REQUEST-STATUS-HEADER)
>                            (REQUEST-STATUS)
>                            [STATUS-INFO]
>                           *[EXTENSION-ATTRIBUTE]
>=20
> Now, the already existing FLOOR-REQUEST-INFORMATION grouped attribute
> would carry '1*(FLOOR-REQUEST-STATUS)' instead of '1*(FLOOR-ID)'
>=20
> The same for the already existing ChairAction message.
>=20
>=20
> Additionally, we would define a new grouped attribute called
> OVERALL-REQUEST-STATUS, whose definition would be almost identical to
> the FLOOR-REQUEST-STATUS attribute. The only difference is that this =
one
> would carry a Floor Request ID instead of a Floor ID. This attribute
> would be used within the FLOOR-REQUEST-INFORMATION attribute, whose =
ABNF
> would become:
>=20
> OLD:
>=20
>     FLOOR-REQUEST-INFORMATION =3D   (FLOOR-REQUEST-INFORMATION-HEADER)
>                                   (REQUEST-STATUS)              <--
>                                 1*(FLOOR-ID)                    <--
>                                   [BENEFICIARY-INFORMATION]
>                                   [REQUESTED-BY-INFORMATION]
>                                   [PRIORITY]
>                                   [PARTICIPANT-PROVIDED-INFO]
>                                   [STATUS-INFO]                 <--
>                                  *[EXTENSION-ATTRIBUTE]
>=20
> NEW:
>=20
>     FLOOR-REQUEST-INFORMATION =3D   (FLOOR-REQUEST-INFORMATION-HEADER)
>                                   (OVERALL-REQUEST-STATUS)
>                                 1*(FLOOR-REQUEST-STATUS)
>                                   [BENEFICIARY-INFORMATION]
>                                   [REQUESTED-BY-INFORMATION]
>                                   [PRIORITY]
>                                   [PARTICIPANT-PROVIDED-INFO]
>                                  *[EXTENSION-ATTRIBUTE]
>=20
>=20
>=20
> Then, we would need to add a brief discussion on queues, indicating =
that
> the queue positions in the OVERALL-REQUEST-STATUS attribute refer to
> positions in a global queue for floor requests and that queue =
positions
> in the FLOOR-REQUEST-STATUS attribute refer to positions in a queue =
for
> floor requests for a particular floor. Of course, implementations are
> free to implement (or provide information about) one, both, or none of
> these queue types.
>=20
> The ChairAction message would become:
>=20
> OLD:
>=20
>     ChairAction  =3D   (COMMON-HEADER)
>                    1*(FLOOR-ID)             <--
>                      (FLOOR-REQUEST-ID)
>                      (REQUEST-STATUS)       <--
>                      [STATUS-INFO]
>                     *[EXTENSION-ATTRIBUTE]
>=20
> NEW:
>=20
>     ChairAction  =3D   (COMMON-HEADER)
>                    1*(FLOOR-REQUEST-STATUS)
>                      (FLOOR-REQUEST-ID)
>                      [STATUS-INFO]
>                     *[EXTENSION-ATTRIBUTE]
>=20
>=20
> A different issue (more easily fixable than the issue above) is that =
the
> FloorRequest and the FloorQuery messages should carry 1*(FLOOR-ID)
> instead of *(FLOOR-ID).
>=20
> Cheers,
>=20
> Gonzalo
>=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 Fri Apr 21 14:50:16 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FX0ho-00070w-Dt; Fri, 21 Apr 2006 14:50:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FX0hm-00070r-Pc
	for xcon@ietf.org; Fri, 21 Apr 2006 14:50:10 -0400
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX0hh-0000PC-Jg
	for xcon@ietf.org; Fri, 21 Apr 2006 14:50:10 -0400
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	A3A354F0001; Fri, 21 Apr 2006 20:49:55 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 21 Apr 2006 20:49:54 +0200
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by
	esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 21 Apr 2006 20:49:54 +0200
Received: from [131.160.126.101] (rvi2-126-101.lmf.ericsson.se
	[131.160.126.101])
	by mail.lmf.ericsson.se (Postfix) with ESMTP id 5BB66236B;
	Fri, 21 Apr 2006 21:49:54 +0300 (EEST)
Message-ID: <44492951.2020802@ericsson.com>
Date: Fri, 21 Apr 2006 21:49:53 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Even, Roni" <roni.even@polycom.co.il>
Subject: NAT Traversal and BFCP WAS (Re: [XCON] Proposed small fixes to BFCP)
References: <144ED8561CE90C41A3E5908EDECE315C036F3834@IsrExch01.israel.polycom.com>
In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C036F3834@IsrExch01.israel.polycom.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Apr 2006 18:49:54.0474 (UTC)
	FILETIME=[610188A0:01C66574]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: Adam Roach <adam@nostrum.com>, Keith Drage <drage@lucent.com>,
	alan@sipstation.com, XCON <xcon@ietf.org>, Joerg Ott <jo@netlab.hut.fi>
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,

you can use ICE (e.g., using a TURN relay) for TCP-based media as well. 
That should cover your scenario. We do not need to develop any 
BFCP-specific extension for NAT traversal.

Thanks,

Gonzalo

Even, Roni wrote:
> Hi guys,
> I may open here a can of worms, but when looking at an implementation that includes BFCP as described in http://www.ietf.org/internet-drafts/draft-even-xcon-pnc-01.txt, we encountered the issue of NAT traversal. The pnc draft addresses multipoint cases but may also be used in a point to point case where one of the endpoints is the BFCP server. Since BFCP is only defined for TCP we feel that there is currently a lack of support for TCP based NAT traversal solutions. Maybe we can consider allowing BFCP over UDP.
> Thanks
> Roni Even 
> 

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



From xcon-bounces@ietf.org Wed Apr 26 18:50:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FYspf-00024u-M9; Wed, 26 Apr 2006 18:50:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FYspe-00024c-Cv; Wed, 26 Apr 2006 18:50:02 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FYspe-0004mM-4Q; Wed, 26 Apr 2006 18:50:02 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10])
	by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k3QMo1vP026680
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 26 Apr 2006 22:50:01 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1FYspd-0002pO-OF; Wed, 26 Apr 2006 18:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1FYspd-0002pO-OF@stiedprstage1.ietf.org>
Date: Wed, 26 Apr 2006 18:50:01 -0400
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: xcon@ietf.org
Subject: [XCON] I-D ACTION:draft-ietf-xcon-common-data-model-00.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 Common Conference Information Data Model for Centralized Conferencing (XCON)
	Author(s)	: O. Novo, et al.
	Filename	: draft-ietf-xcon-common-data-model-00.txt
	Pages		: 57
	Date		: 2006-4-26
	
This document collects, organizes, and describes the conference
variables that have been introduced in various protocol drafts of the
XCON and SIPPING working groups.  The goal of this document is to
allow the conference control protocols to use a unified common  conference information data model for XCON.  This document formally
defines an Extensible Markup Language (XML) Schema that represents
the common conference information in a conferencing server.  The
information is modeled as a series of elements, each of which
contains a set of children and attributes.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-00.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-common-data-model-00.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-common-data-model-00.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: <2006-4-26152936.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-xcon-common-data-model-00.txt

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

Content-Type: text/plain
Content-ID: <2006-4-26152936.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 Apr 28 04:03:29 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FZNwn-00044r-6J; Fri, 28 Apr 2006 04:03:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FZNwm-00044m-Ap
	for xcon@ietf.org; Fri, 28 Apr 2006 04:03:28 -0400
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZNwj-0000As-OO
	for xcon@ietf.org; Fri, 28 Apr 2006 04:03:28 -0400
Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	2B60C4F0002; Fri, 28 Apr 2006 10:03:25 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by
	esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 28 Apr 2006 10:03:24 +0200
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by
	esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 28 Apr 2006 10:03:24 +0200
Received: from [131.160.126.3] (rvi2-126-3.lmf.ericsson.se [131.160.126.3])
	by mail.lmf.ericsson.se (Postfix) with ESMTP id BFAB8236E;
	Fri, 28 Apr 2006 11:03:23 +0300 (EEST)
Message-ID: <4451CC4B.7000801@ericsson.com>
Date: Fri, 28 Apr 2006 11:03:23 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Subject: Re: [XCON] Proposed small fixes to BFCP
References: <4448DFAC.9080009@ericsson.com>
In-Reply-To: <4448DFAC.9080009@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 28 Apr 2006 08:03:24.0290 (UTC)
	FILETIME=[39256E20:01C66A9A]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Cc: Adam Roach <adam@nostrum.com>, Keith Drage <drage@lucent.com>,
	alan@sipstation.com, XCON <xcon@ietf.org>, Joerg Ott <jo@netlab.hut.fi>
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

Adam, Alan,

I would like to, at least, get the "go ahead" from the chairs...

Thanks,

Gonzalo

Gonzalo Camarillo wrote:
> Folks,
> 
> while implementing our BFCP stack (the 'running code' part of the 
> protocol), we have discovered a couple of relatively minor bugs in the 
> BFCP spec that need to be fixed. They are probably too big to be fixed 
> thru RFC editor notes. My suggestion would be to remove the draft from 
> the queue, perform the changes I propose below, and send it back to the 
> queue. Opinions?
> 
> 
> Section 5.3.9 defines the ChairAction message. That message can contain 
> several floors (which belong to the same floor request operation) but 
> can only provide a single queue position (within the REQUEST-STATUS 
> attribute) for all of them. We need to be able to provide different 
> queue positions for different floors (e.g., second for floor 1 and third 
> for floor 2). In order to do this, we need to define a new grouped 
> attribute called FLOOR-REQUEST-STATUS whose definition would be the 
> following:
> 
> Attribute header:
> 
>      0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |x x x x x x x|M|    Length     |           Floor ID            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Attribute ABNF:
> 
>  FLOOR-REQUEST-STATUS =   (FLOOR-REQUEST-STATUS-HEADER)
>                           (REQUEST-STATUS)
>                           [STATUS-INFO]
>                          *[EXTENSION-ATTRIBUTE]
> 
> Now, the already existing FLOOR-REQUEST-INFORMATION grouped attribute 
> would carry '1*(FLOOR-REQUEST-STATUS)' instead of '1*(FLOOR-ID)'
> 
> The same for the already existing ChairAction message.
> 
> 
> Additionally, we would define a new grouped attribute called 
> OVERALL-REQUEST-STATUS, whose definition would be almost identical to 
> the FLOOR-REQUEST-STATUS attribute. The only difference is that this one 
> would carry a Floor Request ID instead of a Floor ID. This attribute 
> would be used within the FLOOR-REQUEST-INFORMATION attribute, whose ABNF 
> would become:
> 
> OLD:
> 
>    FLOOR-REQUEST-INFORMATION =   (FLOOR-REQUEST-INFORMATION-HEADER)
>                                  (REQUEST-STATUS)              <--
>                                1*(FLOOR-ID)                    <--
>                                  [BENEFICIARY-INFORMATION]
>                                  [REQUESTED-BY-INFORMATION]
>                                  [PRIORITY]
>                                  [PARTICIPANT-PROVIDED-INFO]
>                                  [STATUS-INFO]                 <--
>                                 *[EXTENSION-ATTRIBUTE]
> 
> NEW:
> 
>    FLOOR-REQUEST-INFORMATION =   (FLOOR-REQUEST-INFORMATION-HEADER)
>                                  (OVERALL-REQUEST-STATUS)
>                                1*(FLOOR-REQUEST-STATUS)
>                                  [BENEFICIARY-INFORMATION]
>                                  [REQUESTED-BY-INFORMATION]
>                                  [PRIORITY]
>                                  [PARTICIPANT-PROVIDED-INFO]
>                                 *[EXTENSION-ATTRIBUTE]
> 
> 
> 
> Then, we would need to add a brief discussion on queues, indicating that 
> the queue positions in the OVERALL-REQUEST-STATUS attribute refer to 
> positions in a global queue for floor requests and that queue positions 
> in the FLOOR-REQUEST-STATUS attribute refer to positions in a queue for 
> floor requests for a particular floor. Of course, implementations are 
> free to implement (or provide information about) one, both, or none of 
> these queue types.
> 
> The ChairAction message would become:
> 
> OLD:
> 
>    ChairAction  =   (COMMON-HEADER)
>                   1*(FLOOR-ID)             <--
>                     (FLOOR-REQUEST-ID)
>                     (REQUEST-STATUS)       <--
>                     [STATUS-INFO]
>                    *[EXTENSION-ATTRIBUTE]
> 
> NEW:
> 
>    ChairAction  =   (COMMON-HEADER)
>                   1*(FLOOR-REQUEST-STATUS)
>                     (FLOOR-REQUEST-ID)
>                     [STATUS-INFO]
>                    *[EXTENSION-ATTRIBUTE]
> 
> 
> A different issue (more easily fixable than the issue above) is that the 
> FloorRequest and the FloorQuery messages should carry 1*(FLOOR-ID) 
> instead of *(FLOOR-ID).
> 
> Cheers,
> 
> Gonzalo
> 

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



From xcon-bounces@ietf.org Fri Apr 28 19:27:18 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FZcMj-0001AP-Mk; Fri, 28 Apr 2006 19:27:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FZcMh-00015P-OA
	for xcon@ietf.org; Fri, 28 Apr 2006 19:27:11 -0400
Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZcMh-000500-E5
	for xcon@ietf.org; Fri, 28 Apr 2006 19:27:11 -0400
Received: from [172.17.2.251] (vicuna.estacado.net [72.1.129.69])
	(authenticated bits=0)
	by nostrum.com (8.13.6/8.13.4) with ESMTP id k3SNR5iN001275
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Fri, 28 Apr 2006 18:27:06 -0500 (CDT)
	(envelope-from adam@nostrum.com)
Message-ID: <4452A4C9.6010304@nostrum.com>
Date: Fri, 28 Apr 2006 18:27:05 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Subject: Re: [XCON] Proposed small fixes to BFCP
References: <4448DFAC.9080009@ericsson.com> <4451CC4B.7000801@ericsson.com>
In-Reply-To: <4451CC4B.7000801@ericsson.com>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3
Cc: Joerg Ott <jo@netlab.hut.fi>, Keith Drage <drage@lucent.com>,
	alan@sipstation.com, 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 was hoping to hear more from working group members before making the
decision -- but it appears that no one has any comments one way or the
other on the issue. I'll discuss with our AD and try to determine the
best way to move forward.

/a

Gonzalo Camarillo wrote:
> Adam, Alan,
>
> I would like to, at least, get the "go ahead" from the chairs...
>
> Thanks,
>
> Gonzalo
>
> Gonzalo Camarillo wrote:
>> Folks,
>>
>> while implementing our BFCP stack (the 'running code' part of the
>> protocol), we have discovered a couple of relatively minor bugs in
>> the BFCP spec that need to be fixed. They are probably too big to be
>> fixed thru RFC editor notes. My suggestion would be to remove the
>> draft from the queue, perform the changes I propose below, and send
>> it back to the queue. Opinions?
>>
>>
>> Section 5.3.9 defines the ChairAction message. That message can
>> contain several floors (which belong to the same floor request
>> operation) but can only provide a single queue position (within the
>> REQUEST-STATUS attribute) for all of them. We need to be able to
>> provide different queue positions for different floors (e.g., second
>> for floor 1 and third for floor 2). In order to do this, we need to
>> define a new grouped attribute called FLOOR-REQUEST-STATUS whose
>> definition would be the following:
>>
>> Attribute header:
>>
>>      0                   1                   2                   3
>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |x x x x x x x|M|    Length     |           Floor ID            |
>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> Attribute ABNF:
>>
>>  FLOOR-REQUEST-STATUS =   (FLOOR-REQUEST-STATUS-HEADER)
>>                           (REQUEST-STATUS)
>>                           [STATUS-INFO]
>>                          *[EXTENSION-ATTRIBUTE]
>>
>> Now, the already existing FLOOR-REQUEST-INFORMATION grouped attribute
>> would carry '1*(FLOOR-REQUEST-STATUS)' instead of '1*(FLOOR-ID)'
>>
>> The same for the already existing ChairAction message.
>>
>>
>> Additionally, we would define a new grouped attribute called
>> OVERALL-REQUEST-STATUS, whose definition would be almost identical to
>> the FLOOR-REQUEST-STATUS attribute. The only difference is that this
>> one would carry a Floor Request ID instead of a Floor ID. This
>> attribute would be used within the FLOOR-REQUEST-INFORMATION
>> attribute, whose ABNF would become:
>>
>> OLD:
>>
>>    FLOOR-REQUEST-INFORMATION =   (FLOOR-REQUEST-INFORMATION-HEADER)
>>                                  (REQUEST-STATUS)              <--
>>                                1*(FLOOR-ID)                    <--
>>                                  [BENEFICIARY-INFORMATION]
>>                                  [REQUESTED-BY-INFORMATION]
>>                                  [PRIORITY]
>>                                  [PARTICIPANT-PROVIDED-INFO]
>>                                  [STATUS-INFO]                 <--
>>                                 *[EXTENSION-ATTRIBUTE]
>>
>> NEW:
>>
>>    FLOOR-REQUEST-INFORMATION =   (FLOOR-REQUEST-INFORMATION-HEADER)
>>                                  (OVERALL-REQUEST-STATUS)
>>                                1*(FLOOR-REQUEST-STATUS)
>>                                  [BENEFICIARY-INFORMATION]
>>                                  [REQUESTED-BY-INFORMATION]
>>                                  [PRIORITY]
>>                                  [PARTICIPANT-PROVIDED-INFO]
>>                                 *[EXTENSION-ATTRIBUTE]
>>
>>
>>
>> Then, we would need to add a brief discussion on queues, indicating
>> that the queue positions in the OVERALL-REQUEST-STATUS attribute
>> refer to positions in a global queue for floor requests and that
>> queue positions in the FLOOR-REQUEST-STATUS attribute refer to
>> positions in a queue for floor requests for a particular floor. Of
>> course, implementations are free to implement (or provide information
>> about) one, both, or none of these queue types.
>>
>> The ChairAction message would become:
>>
>> OLD:
>>
>>    ChairAction  =   (COMMON-HEADER)
>>                   1*(FLOOR-ID)             <--
>>                     (FLOOR-REQUEST-ID)
>>                     (REQUEST-STATUS)       <--
>>                     [STATUS-INFO]
>>                    *[EXTENSION-ATTRIBUTE]
>>
>> NEW:
>>
>>    ChairAction  =   (COMMON-HEADER)
>>                   1*(FLOOR-REQUEST-STATUS)
>>                     (FLOOR-REQUEST-ID)
>>                     [STATUS-INFO]
>>                    *[EXTENSION-ATTRIBUTE]
>>
>>
>> A different issue (more easily fixable than the issue above) is that
>> the FloorRequest and the FloorQuery messages should carry
>> 1*(FLOOR-ID) instead of *(FLOOR-ID).
>>
>> Cheers,
>>
>> Gonzalo
>>


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



From xcon-bounces@ietf.org Sun Apr 30 04:22:36 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fa7CM-0006bX-K7; Sun, 30 Apr 2006 04:22:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fa7CL-0006Vm-Nm
	for xcon@ietf.org; Sun, 30 Apr 2006 04:22:33 -0400
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 1Fa7CJ-0006cC-2C
	for xcon@ietf.org; Sun, 30 Apr 2006 04:22:33 -0400
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] Proposed small fixes to BFCP
Date: Sun, 30 Apr 2006 11:22:27 +0300
Message-ID: <144ED8561CE90C41A3E5908EDECE315C037AF1B3@IsrExch01.israel.polycom.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [XCON] Proposed small fixes to BFCP
Thread-Index: AcZrG142TSHTpqY7RKqjm2HP60gvRABE7NOg
From: "Even, Roni" <roni.even@polycom.co.il>
To: "Adam Roach" <adam@nostrum.com>,
	"Gonzalo Camarillo" <Gonzalo.Camarillo@ericsson.com>
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 0770535483960d190d4a0d020e7060bd
Cc: Joerg Ott <jo@netlab.hut.fi>, Keith Drage <drage@lucent.com>,
	alan@sipstation.com, 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,
I looked at the changes suggested by Gonzalo and they make sense to me. =
Do not see any issues.
Roni Even

> -----Original Message-----
> From: Adam Roach [mailto:adam@nostrum.com]
> Sent: Saturday, April 29, 2006 2:27 AM
> To: Gonzalo Camarillo
> Cc: Joerg Ott; Keith Drage; alan@sipstation.com; XCON
> Subject: Re: [XCON] Proposed small fixes to BFCP
>=20
> I was hoping to hear more from working group members before making the
> decision -- but it appears that no one has any comments one way or the
> other on the issue. I'll discuss with our AD and try to determine the
> best way to move forward.
>=20
> /a
>=20
> Gonzalo Camarillo wrote:
> > Adam, Alan,
> >
> > I would like to, at least, get the "go ahead" from the chairs...
> >
> > Thanks,
> >
> > Gonzalo
> >
> > Gonzalo Camarillo wrote:
> >> Folks,
> >>
> >> while implementing our BFCP stack (the 'running code' part of the
> >> protocol), we have discovered a couple of relatively minor bugs in
> >> the BFCP spec that need to be fixed. They are probably too big to =
be
> >> fixed thru RFC editor notes. My suggestion would be to remove the
> >> draft from the queue, perform the changes I propose below, and send
> >> it back to the queue. Opinions?
> >>
> >>
> >> Section 5.3.9 defines the ChairAction message. That message can
> >> contain several floors (which belong to the same floor request
> >> operation) but can only provide a single queue position (within the
> >> REQUEST-STATUS attribute) for all of them. We need to be able to
> >> provide different queue positions for different floors (e.g., =
second
> >> for floor 1 and third for floor 2). In order to do this, we need to
> >> define a new grouped attribute called FLOOR-REQUEST-STATUS whose
> >> definition would be the following:
> >>
> >> Attribute header:
> >>
> >>      0                   1                   2                   3
> >>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 =
1
> >>      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>      |x x x x x x x|M|    Length     |           Floor ID           =
 |
> >>      =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >>
> >> Attribute ABNF:
> >>
> >>  FLOOR-REQUEST-STATUS =3D   (FLOOR-REQUEST-STATUS-HEADER)
> >>                           (REQUEST-STATUS)
> >>                           [STATUS-INFO]
> >>                          *[EXTENSION-ATTRIBUTE]
> >>
> >> Now, the already existing FLOOR-REQUEST-INFORMATION grouped =
attribute
> >> would carry '1*(FLOOR-REQUEST-STATUS)' instead of '1*(FLOOR-ID)'
> >>
> >> The same for the already existing ChairAction message.
> >>
> >>
> >> Additionally, we would define a new grouped attribute called
> >> OVERALL-REQUEST-STATUS, whose definition would be almost identical =
to
> >> the FLOOR-REQUEST-STATUS attribute. The only difference is that =
this
> >> one would carry a Floor Request ID instead of a Floor ID. This
> >> attribute would be used within the FLOOR-REQUEST-INFORMATION
> >> attribute, whose ABNF would become:
> >>
> >> OLD:
> >>
> >>    FLOOR-REQUEST-INFORMATION =3D   =
(FLOOR-REQUEST-INFORMATION-HEADER)
> >>                                  (REQUEST-STATUS)              <--
> >>                                1*(FLOOR-ID)                    <--
> >>                                  [BENEFICIARY-INFORMATION]
> >>                                  [REQUESTED-BY-INFORMATION]
> >>                                  [PRIORITY]
> >>                                  [PARTICIPANT-PROVIDED-INFO]
> >>                                  [STATUS-INFO]                 <--
> >>                                 *[EXTENSION-ATTRIBUTE]
> >>
> >> NEW:
> >>
> >>    FLOOR-REQUEST-INFORMATION =3D   =
(FLOOR-REQUEST-INFORMATION-HEADER)
> >>                                  (OVERALL-REQUEST-STATUS)
> >>                                1*(FLOOR-REQUEST-STATUS)
> >>                                  [BENEFICIARY-INFORMATION]
> >>                                  [REQUESTED-BY-INFORMATION]
> >>                                  [PRIORITY]
> >>                                  [PARTICIPANT-PROVIDED-INFO]
> >>                                 *[EXTENSION-ATTRIBUTE]
> >>
> >>
> >>
> >> Then, we would need to add a brief discussion on queues, indicating
> >> that the queue positions in the OVERALL-REQUEST-STATUS attribute
> >> refer to positions in a global queue for floor requests and that
> >> queue positions in the FLOOR-REQUEST-STATUS attribute refer to
> >> positions in a queue for floor requests for a particular floor. Of
> >> course, implementations are free to implement (or provide =
information
> >> about) one, both, or none of these queue types.
> >>
> >> The ChairAction message would become:
> >>
> >> OLD:
> >>
> >>    ChairAction  =3D   (COMMON-HEADER)
> >>                   1*(FLOOR-ID)             <--
> >>                     (FLOOR-REQUEST-ID)
> >>                     (REQUEST-STATUS)       <--
> >>                     [STATUS-INFO]
> >>                    *[EXTENSION-ATTRIBUTE]
> >>
> >> NEW:
> >>
> >>    ChairAction  =3D   (COMMON-HEADER)
> >>                   1*(FLOOR-REQUEST-STATUS)
> >>                     (FLOOR-REQUEST-ID)
> >>                     [STATUS-INFO]
> >>                    *[EXTENSION-ATTRIBUTE]
> >>
> >>
> >> A different issue (more easily fixable than the issue above) is =
that
> >> the FloorRequest and the FloorQuery messages should carry
> >> 1*(FLOOR-ID) instead of *(FLOOR-ID).
> >>
> >> Cheers,
> >>
> >> Gonzalo
> >>
>=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