From xcon-bounces@ietf.org Tue Nov 01 17:09:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX4Jd-0004vD-Gp; Tue, 01 Nov 2005 17:09:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX4Jb-0004tV-GO for xcon@megatron.ietf.org; Tue, 01 Nov 2005 17:09:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20021 for ; Tue, 1 Nov 2005 17:08:48 -0500 (EST) Received: from maillnx-us112.fmr.com ([192.223.198.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX4Y1-0005mw-IM for xcon@ietf.org; Tue, 01 Nov 2005 17:24:06 -0500 Received: from MSGMMKSM02WIN.DMN1.FMR.COM (msgmmksm02win.dmn1.fmr.com [10.33.139.33]) by maillnx-us112.fmr.com (Switch-3.1.2/Switch-3.1.0) with SMTP id jA1M8obA013316 for ; Tue, 1 Nov 2005 17:08:50 -0500 Received: from MSGMMKIV02WIN.DMN1.FMR.COM (10.33.148.31) by MSGMMKSM02WIN.DMN1.FMR.COM (Sigaba Gateway v3.83) with ESMTP id 52291556; Tue, 01 Nov 2005 17:08:50 -0500 Received: from MSGMROIM01WIN.DMN1.FMR.COM ([172.26.2.194]) by MSGMMKIV02WIN.DMN1.FMR.COM with SMTP_server; Tue, 01 Nov 2005 17:08:49 -0500 Received: from msgmroclm2win.fmr.com ([10.37.181.20]) by MSGMROIM01WIN.DMN1.FMR.COM with Microsoft SMTPSVC(5.0.2195.6713); Tue, 1 Nov 2005 17:08:49 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Nov 2005 17:08:48 -0500 Message-ID: Thread-Topic: Comments on draft-levin-xcon-cccp-03 thread-index: AcXfMNXz7wqoeBotSYqoUKTvwzEa6A== From: "Morgan, Dave" To: "Orit Levin" , "Even, Roni" X-OriginalArrivalTime: 01 Nov 2005 22:08:49.0647 (UTC) FILETIME=[D64927F0:01C5DF30] X-Spam-Score: 2.9 (++) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 Cc: XCON Subject: [XCON] Comments on draft-levin-xcon-cccp-03 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1812603628==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1812603628== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DF30.D5DE40A0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DF30.D5DE40A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Orit, Roni, and Pierre, here's my comments on your draft=20 =20 1. I like how the four "operations" "add", "modify", "delete" and "get" are used for each element. Is it the case that "add", "modify" and "delete" acting on the element can return the response codes you describe, while "get" returns a response code and the desired XML code? Along that line, I'm wondering why the addconference response in 6.2.1 returned the XML code in the request. Also I see in 6.5.1 that addEndpointMedia can return a new value for the "media-id." So is it the case that any request can have XML code returned in the corresponding response? =20 2. What you propose for system primitives works well. I can envision how "gettemplates" returns the data model of the conference with all the elements listed. These are in turn the elements that the control protocol can successfully manipulate with the four operations. Operations on all other elements not listed in the template (or conference object in general) should return a failure. Is that how you envision it to work? =20 3. Do you think the client should be able to change all if not most of the conference elements defined in the conference object? I think that is a reasonable expectation. If that's the case, then the number of transactions you have to define is going to be very large. For example, in addition to what you've defined you could have the following requests: "modifycodec", "getmaximum-user-count", addsecurity-level", "modifylayout", modifyallow-conference-state", etc. It would be nice to separate the operations from the element (such as ) so that coding for the permutations does not overwhelm the client. But I can't think of a way to do that and transmit well-formed XML in the request. How are you planning to address all the permutations? =20 4. Do you intend to say anything about the CCCP server in this draft? Are you going to talk about how the server can have data access rights to manipulate the values of the elements in the conference object? When Oscar and I discussed data access rights we agreed on two things, that the manipulation would be based on the roles, and that the elements should have attributes of "read-write" and "read-only" (although we were hoping to see some comments/suggestions on the mailing list on the mechanism for specifying the "privileges-control-list"). So perhaps when the CCCP request comes in from a client, the CCCP server (which I assume knows the role of the entity on that client) can examine the conference object and determine if the operation succeeds. For example, if the entity is a "moderator" and the request is to "modifyallow-sidebars" and is set in the conference object then the operation should return a failure with a reason code for "unauthorized." =20 5. Section 6.1.1, Cancel: Why did you use "MCU" in the example request to=3Dhttps://Mcu55.company.com:444/MCU? Aren't you = communicating with the CCCP server as you describe it in 6.4.1? =20 6. Section 6.3.3, modifyUserRoles: We need to get on the same page with respect to user roles. I see a "user-roles-type" in sipping-conference-package-12 but not a "user-roles" defined (ah, I found it in xcon-conference-package-ext-00). In xcon-media-template-03 and xcon-roles-00 we used "role-type" instead of "user-roles-type." =20 Dave =20 =20 ------------------------------------------------------------------------ David P. Morgan, PhD=20 VP, Architecture & Planning=20 Fidelity Investments Systems Company - Telecom=20 Phone: 617 563-2178=20 Fax: 617 385 2122=20 Mailing: 82 Devonshire St, MZ V8C=20 Boston, MA 02109-3614=20 Office: 245 Summer Street, 8th Floor=20 =20 ------_=_NextPart_001_01C5DF30.D5DE40A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Orit, Roni, and = Pierre, here’s my=20 comments on your draft

 

  1. I=20 like how the four “operations” “add”, = “modify”, “delete” and “get” are = used=20 for each element.  Is it = the case=20 that “add”, “modify” and “delete” = acting on the element can return the=20 response codes you describe, while “get” returns a = response code and the=20 desired XML code?  Along = that=20 line, I’m wondering why the addconference response in 6.2.1 = returned the XML=20 code in the request.  = Also I see=20 in 6.5.1 that addEndpointMedia can return a new value for the = “media-id.”  So is it the case that any request = can have=20 XML code returned in the corresponding response?

 

  1. What=20 you propose for system primitives works well.  I can envision how = “gettemplates”=20 returns the data model of the conference with all the elements = listed.  These are in turn the = elements that=20 the control protocol can successfully manipulate with the four=20 operations.  Operations = on all=20 other elements not listed in the template (or conference object in = general)=20 should return a failure.  = Is that=20 how you envision it to work?

 

  1. Do=20 you think the client should be able to change all if not most of the=20 conference elements defined in the conference object?  I think that is a reasonable = expectation.  If = that’s the case,=20 then the number of transactions you have to define is going to be very = large.  For example, in = addition=20 to what you’ve defined you could have the following requests: = “modifycodec”,=20 “getmaximum-user-count”, addsecurity-level”, = “modifylayout”,=20 modifyallow-conference-state”, etc. =20 It would be nice to separate the operations from the element = (such as=20 <modify codec/>) so that coding for the permutations does not = overwhelm=20 the client.  But I = can’t think of=20 a way to do that and transmit well-formed XML in the request.  How are you planning to address all the=20 permutations?

 

  1. Do=20 you intend to say anything about the CCCP server in this draft?  Are you going to talk about = how the=20 server can have data access rights to manipulate the values of the = elements in=20 the conference object?  When=20 Oscar and I discussed = data access=20 rights we agreed on two things, that the manipulation would be based = on the=20 roles, and that the elements should have attributes of = “read-write” and=20 “read-only” (although we were hoping to see some = comments/suggestions on the=20 mailing list on the mechanism for specifying the = “privileges-control-list”).=20  So perhaps when the = CCCP request=20 comes in from a client, the CCCP server (which I assume knows the role = of the=20 entity on that client) can examine the conference object and determine = if the=20 operation succeeds.  =  For example, if the entity is = a=20 “moderator” and the request is to = “modifyallow-sidebars” and=20 <allow-sidebars read-only=3D”moderator” = read-write=3D”creator”/> is set in=20 the conference object then the operation should return a failure with = a reason=20 code for “unauthorized.”

 

  1. Section=20 6.1.1, Cancel:  Why did = you use=20 “MCU” in the example request to=3Dhttps://Mcu55.company.com:444/= MCU?  Aren’t you = communicating with the CCCP=20 server as you describe it in 6.4.1?

 

  1. Section=20 6.3.3, modifyUserRoles:  = We need=20 to get on the same page with respect to user roles.  I see a = “user-roles-type” in=20 sipping-conference-package-12 but not a “user-roles” = defined (ah, I found it=20 in xcon-conference-package-ext-00).  In xcon-media-template-03 and = xcon-roles-00 we used “role-type” instead of = “user-roles-type.”

 

Dave

 
 

----------------------------------------------------------------= --------=20
David P. Morgan, = PhD=20
VP, = Architecture=20 & Planning
Fidelity Investments Systems Company - Telecom =
Phone:  = 617=20 563-2178
Fax:      617 385 2122 =
Mailing: 82 = Devonshire St, MZ=20 V8C
          &nbs= p;=20 Boston, MA 02109-3614
Office:   245 Summer Street, 8th=20 Floor


 
------_=_NextPart_001_01C5DF30.D5DE40A0-- --===============1812603628== 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 --===============1812603628==-- From xcon-bounces@ietf.org Tue Nov 01 19:46:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX6lN-0004zY-AW; Tue, 01 Nov 2005 19:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX6lA-0004yd-Nz for xcon@megatron.ietf.org; Tue, 01 Nov 2005 19:45:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27088 for ; Tue, 1 Nov 2005 19:45:27 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX6ze-0002qd-MT for xcon@ietf.org; Tue, 01 Nov 2005 20:00:47 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 1 Nov 2005 16:45:37 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.14]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Nov 2005 16:45:36 -0800 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 Date: Tue, 1 Nov 2005 16:45:36 -0800 Message-ID: Thread-Topic: Comments on draft-levin-xcon-cccp-03 thread-index: AcXfMNXz7wqoeBotSYqoUKTvwzEa6AAC8NLQ From: "Orit Levin" To: "Morgan, Dave" , "Even, Roni" X-OriginalArrivalTime: 02 Nov 2005 00:45:36.0922 (UTC) FILETIME=[BD7567A0:01C5DF46] X-Spam-Score: 1.9 (+) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Cc: XCON Subject: [XCON] RE: Comments on draft-levin-xcon-cccp-03 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Dave, Thank you very much for your comments! My answers are inline. I think that my co-authors will be able to = provide additional insights including their experience with older = conference control protocols implementation. Orit. ________________________________________ From: Morgan, Dave [mailto:Dave.Morgan@FMR.COM]=20 Sent: Tuesday, November 01, 2005 2:09 PM To: Orit Levin; Even, Roni Cc: XCON Subject: Comments on draft-levin-xcon-cccp-03 Orit, Roni, and Pierre, here's my comments on your draft=20 1. I like how the four "operations" "add", "modify", "delete" and "get" = are used for each element. Is it the case that "add", "modify" and = "delete" acting on the element can return the response codes you = describe, while "get" returns a response code and the desired XML code? = Along that line, I'm wondering why the addconference response in 6.2.1 = returned the XML code in the request. Also I see in 6.5.1 that = addEndpointMedia can return a new value for the "media-id."=A0 So is it = the case that any request can have XML code returned in the = corresponding response? OL: Every response MUST include the code on the CCCP response level. = Additionally, every primitive can define in XML a set of its own = specific response codes (and additional data). In the current XML = schema, all the primitives have their own codes defined, but they are = optional and therefore are not used in all the examples. BTW, note also that most of the responses can optionally carry the = resultant XML data just for feedback. It is not required, though, = because in the success case, the resultant XML should be obvious to the = CCCP client. 2. What you propose for system primitives works well. I can envision = how "gettemplates" returns the data model of the conference with all the = elements listed. These are in turn the elements that the control = protocol can successfully manipulate with the four operations. = Operations on all other elements not listed in the template (or = conference object in general) should return a failure. Is that how you = envision it to work? OL: Every implemented primitive must first be defined in the CCCP XML. = Possible primitives are not restricted to add/modify/delete/get only. = There is an explicit moveUserToSidebar() primitive, as an example. CCCP = Server can choose to support just a subset of primitives. If the = protocol takes off in the IETF, we will need to add the = getSupportedPrimitives() primitive... 3. Do you think the client should be able to change all if not most of = the conference elements defined in the conference object? I think that = is a reasonable expectation. If that's the case, then the number of = transactions you have to define is going to be very large. For example, = in addition to what you've defined you could have the following = requests: "modifycodec", "getmaximum-user-count", addsecurity-level", = "modifylayout", modifyallow-conference-state", etc. It would be nice to = separate the operations from the element (such as ) so = that coding for the permutations does not overwhelm the client. But I = can't think of a way to do that and transmit well-formed XML in the = request. How are you=A0planning to address all the permutations? OL: No, no. The main objects (conference, user, endpoint, ...) need to = be accessed explicitly. The most frequently used objects makes sense to = update directly too. The modifyUserRoles() primitive is used to = illustrate this. Rather than that, I think that most of the information = will be accessed and modified through their parent objects. The "modify" = request carries a "partial" information - i.e. just the information to = be modified.=20 4. Do you intend to say anything about the CCCP server in this draft? = Are you going to talk about how the server can have data access rights = to manipulate the values of the elements in the conference object? When = Oscar and I discussed data access rights we agreed on two things, that = the manipulation would be based on the roles, and that the elements = should have attributes of "read-write" and "read-only" (although we were = hoping to see some comments/suggestions on the mailing list on the = mechanism for specifying the "privileges-control-list"). So perhaps = when the CCCP request comes in from a client, the CCCP server (which I = assume knows the role of the entity on that client) can examine the = conference object and determine if the operation succeeds. For = example, if the entity is a "moderator" and the request is to = "modifyallow-sidebars" and is set in the conference object then the = operation should return a failure with a reason code for "unauthorized." OL: As above, this draft shows the direction in its raw form. If XCON = likes it, we will definitely need to add the access control definitions. 5. Section 6.1.1, Cancel: Why did you use "MCU" in the example request = to=3Dhttps://Mcu55.company.com:444/MCU? Aren't you communicating with = the CCCP server as you describe it in 6.4.1? OL: The MCU runs the CCCP server inside :-) but it is a good idea to = make the example simpler and more explicit. 6. Section 6.3.3, modifyUserRoles: We need to get on the same page with = respect to user roles. I see a "user-roles-type" in = sipping-conference-package-12 but not a "user-roles" defined (ah, I = found it in xcon-conference-package-ext-00). In xcon-media-template-03 = and xcon-roles-00 we used "role-type" instead of "user-roles-type." OL: Yes, I agree. (and I will check the XML syntax.) Dave =A0 =A0 ------------------------------------------------------------------------ = David P. Morgan, PhD=20 VP, Architecture & Planning=20 Fidelity Investments Systems Company - Telecom=20 Phone:=A0 617 563-2178=20 Fax:=A0=A0=A0=A0=A0 617 385 2122=20 Mailing: 82 Devonshire St, MZ V8C=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Boston, MA 02109-3614=20 Office:=A0=A0 245 Summer Street, 8th Floor=20 =A0 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Nov 03 20:29:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXqO6-0008R2-Bh; Thu, 03 Nov 2005 20:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXqO5-0008Qx-3i for xcon@megatron.ietf.org; Thu, 03 Nov 2005 20:29:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11778 for ; Thu, 3 Nov 2005 20:28:38 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXqcx-0003ZZ-Pu for xcon@ietf.org; Thu, 03 Nov 2005 20:44:25 -0500 Received: from [172.17.2.251] (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jA41SQIR029751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Nov 2005 19:28:29 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <436AB93A.2030004@nostrum.com> Date: Thu, 03 Nov 2005 19:28:26 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo Subject: Re: [XCON] Draft defining a Common Data Model for XCON References: <4333F093.7050601@ericsson.com> In-Reply-To: <4333F093.7050601@ericsson.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: Dave.Morgan@fmr.com, XCON X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org A quick comment on the document: the handling of times in this document seems to be at odds with the decision that we use RFC2445 iCal objects to talk about times. In particular, it introduces its own recurrence mechanism that appears to be rather different than what RFC2445 defines. In particular, if I understood consensus correctly, we should be using *literal* iCal syntax to convey this information; so, for example, the section of the draft that reads: 7days 2006-10-17T09:30:00-05:00 2006-10-17T11:30:00-05:00 2006-10-17T12:00:00-05:00 Should instead look something more like: BEGIN:VCALENDAR PRODID:-//LlamaSpinner Inc.//NONSGML CamelCall//EN VERSION:2.0 BEGIN:VEVENT DTSTAMP:20051103T140728Z UID:sd08f@example.com ORGANIZER:MAILTO:bob@example.com DTSTART:20061017T143000Z RRULE:FREQ=WEEKLY DTEND:20061017T163000Z -60 60 9000 /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Nov 08 20:07:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZeRC-000103-HG; Tue, 08 Nov 2005 20:07:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZeRA-0000zt-V4 for xcon@megatron.ietf.org; Tue, 08 Nov 2005 20:07:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00343 for ; Tue, 8 Nov 2005 20:07:13 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZeh3-0002dO-8G for xcon@ietf.org; Tue, 08 Nov 2005 20:24:07 -0500 Received: from [209.52.106.162] (pp106-162.bctel.ca [209.52.106.162]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jA917YBw065201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Nov 2005 19:07:35 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <43714BD6.90100@nostrum.com> Date: Tue, 08 Nov 2005 17:07:34 -0800 From: Adam Roach 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.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 209.52.106.162 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Subject: [XCON] Proposed WG Milestones X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org [as chair] At today's face-to-face meeting, the chairs proposed a new milestone schedule. No discussion ensued. The specific proposals are as follows: Jul 06 - Submit Framework and Data Model for publication as PS Aug 06 - Submit Event Notification Package for publication as PS Oct 06 - Submit Common Conference Information Definition for publication as PS Nov 06 - Submit Conference Template Definition for publication as PS Dec 06 - Submit Conference Control Protocol for publication as PS Dec 06 - Set milestones for any IM-related conferencing work Our current plan is to have the revised milestones officially adopted early next month. Interested parties should provide feedback on these milestones on this list by the end of November. Thanks. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Nov 09 11:11:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZsY2-00020w-NQ; Wed, 09 Nov 2005 11:11:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZsY1-0001zB-JG for xcon@megatron.ietf.org; Wed, 09 Nov 2005 11:11:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18689 for ; Wed, 9 Nov 2005 11:11:13 -0500 (EST) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZso3-0000WB-4R for xcon@ietf.org; Wed, 09 Nov 2005 11:28:16 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 17:11:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Nov 2005 17:11:26 +0100 Message-ID: Thread-Topic: Comment on draft-boulton-xcon-msrp-conferencing-02 Thread-Index: AcXlSDTJFl0eWOWTQ/W1DD1XcuJS4g== From: "MARJOU Xavier RD-MAPS-LAN" To: X-OriginalArrivalTime: 09 Nov 2005 16:11:33.0732 (UTC) FILETIME=[40CA1A40:01C5E548] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: xcon@ietf.org Subject: [XCON] Comment on draft-boulton-xcon-msrp-conferencing-02 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Hi,=20 Some time ago, in the SIMPLE WG, there was a comment that there is a problem when a participant sends large amounts of data and one of the "receiving" participants is behind a low bandwidth access link.=20 I think that this point must be addressed in the draft: what happens in such a case? Does the MSRP conference server remove such a participant, or is the "sending" participant asked to slow down its sending flow? (depending on the solution there may be extensions needed within the MSRP) Perhaps that some work from Reliable Multicast Transport WG could be re-used. I don't know about this WG, but when I look at its charter, it seems that similar issues are addressed. Xavier _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Nov 09 12:21:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZte0-0006E6-0q; Wed, 09 Nov 2005 12:21:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtdy-0006Br-9i for xcon@megatron.ietf.org; Wed, 09 Nov 2005 12:21:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23559 for ; Wed, 9 Nov 2005 12:21:25 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZttz-0002ng-Ka for xcon@ietf.org; Wed, 09 Nov 2005 12:38:30 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 09 Nov 2005 09:21:43 -0800 X-IronPort-AV: i="3.97,309,1125903600"; d="scan'208"; a="362883065:sNHT25468330" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA9HLEc7029660; Wed, 9 Nov 2005 09:21:40 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 09:21:38 -0800 Received: from [10.89.16.53] ([10.89.16.53]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Nov 2005 09:21:38 -0800 Message-ID: <43723017.8030405@cisco.com> Date: Wed, 09 Nov 2005 12:21:27 -0500 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MARJOU Xavier RD-MAPS-LAN Subject: Re: [XCON] Comment on draft-boulton-xcon-msrp-conferencing-02 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2005 17:21:38.0315 (UTC) FILETIME=[0AEA8DB0:01C5E552] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: cboulton@ubiquitysoftware.com, xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Xavier, This is a conference server after all, so it should probably be prepared to do some work. In this case I would hope the focus would buffer the message and dribble it to the slow recipient, without impacting other participants. Of course, if data keeps coming at an aggregate rate greater than this slow participant can receive it, the buffer can grow without bound. So at some point the focus will have to stop buffering. Then it needs to give up on the slow participant. Paul MARJOU Xavier RD-MAPS-LAN wrote: > Hi, > > Some time ago, in the SIMPLE WG, there was a comment that there is a > problem when a participant sends large amounts of data and one of the > "receiving" participants is behind a low bandwidth access link. > > I think that this point must be addressed in the draft: what happens in > such a case? Does the MSRP conference server remove such a participant, > or is the "sending" participant asked to slow down its sending flow? > (depending on the solution there may be extensions needed within the > MSRP) > > Perhaps that some work from Reliable Multicast Transport WG could be > re-used. I don't know about this WG, but when I look at its charter, it > seems that similar issues are addressed. > > Xavier > > _______________________________________________ > 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 Nov 09 13:51:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZv38-00006r-ON; Wed, 09 Nov 2005 13:51:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZv37-00006G-Ki for xcon@megatron.ietf.org; Wed, 09 Nov 2005 13:51:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29798 for ; Wed, 9 Nov 2005 13:51:30 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZvJA-0005ij-IC for xcon@ietf.org; Wed, 09 Nov 2005 14:08:34 -0500 Received: from [209.52.106.162] (pp106-162.bctel.ca [209.52.106.162]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jA9IpUEw061332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Nov 2005 12:51:31 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4372452F.6060108@nostrum.com> Date: Wed, 09 Nov 2005 10:51:27 -0800 From: Adam Roach 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.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 209.52.106.162 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [XCON] BFCP: Security Considerations X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org [as chair] In yesterday's face-to-face meeting, we had a discussion around security mechanisms for BFCP. The discussion in that meeting concluded the following: * Digest authentication will be removed from the base draft; * TLS will be made mandatory to implement (although optional to use); * The use of Digest Authentication will be added on as an extension to BFCP, so as to support the use case in which a conference participant is using a conference-unaware client but wants to participate in floor control via (e.g.) a web interface. This message is intended to solicit discussion on the mailing list on this topic. Interested parties should comment as soon as possible. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Nov 10 21:21:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaOY7-0006SF-4R; Thu, 10 Nov 2005 21:21:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaOY5-0006S7-Tb for xcon@megatron.ietf.org; Thu, 10 Nov 2005 21:21:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03727 for ; Thu, 10 Nov 2005 21:21:25 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaOoM-0004Fv-EJ for xcon@ietf.org; Thu, 10 Nov 2005 21:38:46 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 004BE77E; Fri, 11 Nov 2005 03:20:29 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Nov 2005 03:20:28 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 Nov 2005 03:20:28 +0100 Received: from [131.160.126.77] (rvi2-126-77.lmf.ericsson.se [131.160.126.77]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 80E4A283B; Fri, 11 Nov 2005 04:20:20 +0200 (EET) Message-ID: <4373FFDF.3030205@ericsson.com> Date: Fri, 11 Nov 2005 04:20:15 +0200 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach Subject: Re: [XCON] BFCP: Security Considerations References: <4372452F.6060108@nostrum.com> In-Reply-To: <4372452F.6060108@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2005 02:20:28.0315 (UTC) FILETIME=[7B82CEB0:01C5E666] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Hi, I just would like to point out that the MMUSIC draft will normatively depend on tls-comedia. Cheers, Gonzalo Adam Roach wrote: > [as chair] > > In yesterday's face-to-face meeting, we had a discussion around security > mechanisms for BFCP. The discussion in that meeting concluded the > following: > > * Digest authentication will be removed from the base draft; > * TLS will be made mandatory to implement (although optional to use); > * The use of Digest Authentication will be added on as an extension > to BFCP, so as to support the use case in which a conference > participant is using a conference-unaware client but wants to > participate in floor control via (e.g.) a web interface. > > This message is intended to solicit discussion on the mailing list on > this topic. Interested parties should comment as soon as possible. > > /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 Mon Nov 14 15:27:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebkv5-0001jw-2Z; Mon, 14 Nov 2005 15:27:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebkv4-0001jh-Dp for xcon@megatron.ietf.org; Mon, 14 Nov 2005 15:27:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21184 for ; Mon, 14 Nov 2005 15:26:40 -0500 (EST) Received: from maillnx-us112.fmr.com ([192.223.198.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EblC7-0002to-DR for xcon@ietf.org; Mon, 14 Nov 2005 15:44:52 -0500 Received: from MSGMMKSM02WIN.DMN1.FMR.COM (msgmmksm02win.dmn1.fmr.com [10.33.139.33]) by maillnx-us112.fmr.com (Switch-3.1.2/Switch-3.1.0) with SMTP id jAEKQubA011837 for ; Mon, 14 Nov 2005 15:26:56 -0500 Received: from MSGMMKIV02WIN.DMN1.FMR.COM (10.33.148.31) by MSGMMKSM02WIN.DMN1.FMR.COM (Sigaba Gateway v3.83) with ESMTP id 54117400; Mon, 14 Nov 2005 15:26:55 -0500 Received: from MSGMROIM01WIN.DMN1.FMR.COM ([172.26.2.194]) by MSGMMKIV02WIN.DMN1.FMR.COM with SMTP_server; Mon, 14 Nov 2005 15:26:55 -0500 Received: from msgmroclm2win.fmr.com ([10.37.181.20]) by MSGMROIM01WIN.DMN1.FMR.COM with Microsoft SMTPSVC(5.0.2195.6713); Mon, 14 Nov 2005 15:26:55 -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] Proposed WG Milestones Date: Mon, 14 Nov 2005 15:26:54 -0500 Message-ID: Thread-Topic: [XCON] Proposed WG Milestones thread-index: AcXkyqiViqp9z7//Qcm6SMqttU1M/wEjkrtA From: "Morgan, Dave" To: "Adam Roach" , X-OriginalArrivalTime: 14 Nov 2005 20:26:55.0297 (UTC) FILETIME=[C1382310:01C5E959] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Adam, I have a question on the Event Notification Package for publication and it's August delivery date. Who, is working on it? I haven't seen any progress in this area. Is there an assumption that it's going to be derived from draft-ietf-sipping-conference-package? Unless there's something I'm missing, I would recommend moving that milestone back, at least until Dec '06. Dave ------------------------------------------------------------------------ David P. Morgan, PhD VP, Architecture & Planning Fidelity Investments Systems Company - Telecom Phone: 617 563-2178 Fax: 617 385 2122 Mailing: 82 Devonshire St, MZ V8C Boston, MA 02109-3614 Office: 245 Summer Street, 8th Floor -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Tuesday, November 08, 2005 8:08 PM To: xcon@ietf.org Subject: [XCON] Proposed WG Milestones [as chair] At today's face-to-face meeting, the chairs proposed a new milestone=20 schedule. No discussion ensued. The specific proposals are as follows: Jul 06 - Submit Framework and Data Model for publication as PS Aug 06 - Submit Event Notification Package for publication as PS Oct 06 - Submit Common Conference Information Definition for publication as PS Nov 06 - Submit Conference Template Definition for publication as PS Dec 06 - Submit Conference Control Protocol for publication as PS Dec 06 - Set milestones for any IM-related conferencing work Our current plan is to have the revised milestones officially adopted=20 early next month. Interested parties should provide feedback on these=20 milestones on this list by the end of November. 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 Wed Nov 16 19:21:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcXXJ-0007Ow-Df; Wed, 16 Nov 2005 19:21:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcXXJ-0007Or-1m for xcon@megatron.ietf.org; Wed, 16 Nov 2005 19:21:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10095 for ; Wed, 16 Nov 2005 19:21:22 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcXom-0000NG-2G for xcon@ietf.org; Wed, 16 Nov 2005 19:40:01 -0500 Received: from [172.17.2.251] (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jAH0LaSE031616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Nov 2005 18:21:37 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <437BCD0F.80007@nostrum.com> Date: Wed, 16 Nov 2005 18:21:35 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: XCON-IETF X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [XCON] Slides and minutes X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org [as chair] The slides and preliminary (raw) minutes from the Vancouver meeting are now available at: http://www.softarmor.com/xcon/meets/ietf64/ /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Nov 16 19:32:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcXhZ-0001Y1-UU; Wed, 16 Nov 2005 19:32:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcXhY-0001XY-8b for xcon@megatron.ietf.org; Wed, 16 Nov 2005 19:32:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10640 for ; Wed, 16 Nov 2005 19:31:57 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcXz5-0000jr-Ds for xcon@ietf.org; Wed, 16 Nov 2005 19:50:39 -0500 Received: from [172.17.2.251] (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jAH0WTe8032300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Nov 2005 18:32:30 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <437BCF9C.2060907@nostrum.com> Date: Wed, 16 Nov 2005 18:32:28 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: XCON-IETF X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [XCON] Call for Consensus and Discussion: Data Model X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org [as chair] In Vancouver, there was considerable discussion around the XCON data model. There seemed to be considerable consensus around the position that we would use the XML schema defined in draft-ietf-sipping-conference-package-12 as the basis for the data model used in XCON. There was also a sentiment expressed that this schema needs additional elements added so that it can express all the information relevant to the data model we are defining in XCON. draft-novo-xcon-common-data-model-00 purports to be a starting point for defining such additional elements. This message is intended to (a) verify the consensus to use the conference event package as a starting point, and (b) spur discussion around what additional data items are necessary to make it complete for XCON's purposes. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Nov 17 05:35:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ech6q-0000wo-Ot; Thu, 17 Nov 2005 05:35:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ech6p-0000w9-0q for xcon@megatron.ietf.org; Thu, 17 Nov 2005 05:35:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12477 for ; Thu, 17 Nov 2005 05:34:41 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EchOQ-0003yv-70 for xcon@ietf.org; Thu, 17 Nov 2005 05:53:27 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 911364F0005; Thu, 17 Nov 2005 10:31:32 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 10:31:26 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 10:31:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Call for Consensus and Discussion: Data Model Date: Thu, 17 Nov 2005 10:29:31 +0100 Message-ID: Thread-Topic: [XCON] Call for Consensus and Discussion: Data Model Thread-Index: AcXrDl82+BVqgxUxTt+4MLb/K/Tr3gASPfkg From: "Oscar Novo (JO/LMF)" To: "Adam Roach" , "XCON-IETF" X-OriginalArrivalTime: 17 Nov 2005 09:31:02.0636 (UTC) FILETIME=[A071DAC0:01C5EB59] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Thanks Adam for your help.=20 I think it's good idea to start discussing in the mailing list the elements we need to define in the Data Model. I agree the Data Model draft is too SIP-dependent and should have additional items but, as is written in the document, this first version only try based on the SIP event package to collect the data model information introduce for other draft (it does NOT define new elements) that's why is too SIP-dependent. This is one thing we should change in the next version of the draft. There are more open issues that we should discuss as well. All your comments are welcome. Oscar -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Adam Roach Sent: 17. marraskuuta 2005 2:32 To: XCON-IETF Subject: [XCON] Call for Consensus and Discussion: Data Model [as chair] In Vancouver, there was considerable discussion around the XCON data model. There seemed to be considerable consensus around the position that we would use the XML schema defined in draft-ietf-sipping-conference-package-12 as the basis for the data model used in XCON. There was also a sentiment expressed that this schema needs additional elements added so that it can express all the information relevant to the data model we are defining in XCON.=20 draft-novo-xcon-common-data-model-00 purports to be a starting point for defining such additional elements. This message is intended to (a) verify the consensus to use the conference event package as a starting point, and (b) spur discussion around what additional data items are necessary to make it complete for XCON's purposes. /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 Nov 17 16:00:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecqs2-0001ij-Cr; Thu, 17 Nov 2005 16:00:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecqrz-0001hV-4q for xcon@megatron.ietf.org; Thu, 17 Nov 2005 16:00:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21896 for ; Thu, 17 Nov 2005 15:59:59 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecr9e-00015Q-PZ for xcon@ietf.org; Thu, 17 Nov 2005 16:18:53 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 17 Nov 2005 13:00:30 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Nov 2005 13:00:30 -0800 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] Call for Consensus and Discussion: Data Model Date: Thu, 17 Nov 2005 13:00:28 -0800 Message-ID: Thread-Topic: [XCON] Call for Consensus and Discussion: Data Model Thread-Index: AcXrDl82+BVqgxUxTt+4MLb/K/Tr3gASPfkgABdx0GA= From: "Orit Levin" To: "Oscar Novo \(JO/LMF\)" , "Adam Roach" , "XCON-IETF" X-OriginalArrivalTime: 17 Nov 2005 21:00:30.0308 (UTC) FILETIME=[F17FAA40:01C5EBB9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: jari.urpalainen@nokia.com X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org First, I would like to restate my support for the concensus below. =20 One of the major aspects to be addressed in the XCON data model is how to make it extensible by both standard and vendor specific content. I started this discussion in http://www.ietf.org/internet-drafts/draft-levin-xcon-conference-package- ext-00.txt and presented the requirements in http://www.softarmor.com/xcon/meets/ietf64/slides/levin-conf-pkg-ext-iet f64.ppt. During the meeting Jari expressed his preference to just using RelaxNG for XCON instead, but this would require getting approval from the XML directorate and other interested parties. Jari also volunteered to talk to the "XML directorate" regarding this topic. My preference would be to still take the precautions and RECOMMEND the simple conventions suggested in http://www.ietf.org/internet-drafts/draft-levin-xcon-conference-package- ext-00.txt in order to be compatible with the strict standard-compliant XML compilers and not just RelaxNG. In any case, I suggest that we incorporate the alternatives into the common data draft and continue investigating both directions. Thanks a lot, Orit. > -----Original Message----- > From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On=20 > Behalf Of Oscar Novo (JO/LMF) > Sent: Thursday, November 17, 2005 1:30 AM > To: Adam Roach; XCON-IETF > Subject: RE: [XCON] Call for Consensus and Discussion: Data Model >=20 > Thanks Adam for your help.=20 > I think it's good idea to start discussing in the mailing=20 > list the elements we need to define in the Data Model. I=20 > agree the Data Model draft is too SIP-dependent and should=20 > have additional items but, as is written in the document,=20 > this first version only try based on the SIP event package to=20 > collect the data model information introduce for other draft=20 > (it does NOT define new elements) that's why is too SIP-dependent. > This is one thing we should change in the next version of the draft. > There are more open issues that we should discuss as well.=20 > All your comments are welcome. >=20 > Oscar >=20 > -----Original Message----- > From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On=20 > Behalf Of Adam Roach > Sent: 17. marraskuuta 2005 2:32 > To: XCON-IETF > Subject: [XCON] Call for Consensus and Discussion: Data Model >=20 > [as chair] >=20 > In Vancouver, there was considerable discussion around the=20 > XCON data model. There seemed to be considerable consensus=20 > around the position that we would use the XML schema defined in > draft-ietf-sipping-conference-package-12 as the basis for the=20 > data model used in XCON. >=20 > There was also a sentiment expressed that this schema needs=20 > additional elements added so that it can express all the=20 > information relevant to the data model we are defining in XCON.=20 > draft-novo-xcon-common-data-model-00 purports to be a=20 > starting point for defining such additional elements. >=20 > This message is intended to (a) verify the consensus to use=20 > the conference event package as a starting point, and (b)=20 > spur discussion around what additional data items are=20 > necessary to make it complete for XCON's purposes. >=20 > /a >=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 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Nov 18 03:59:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed25l-0006uu-1T; Fri, 18 Nov 2005 03:59:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed25j-0006ud-Ch for xcon@megatron.ietf.org; Fri, 18 Nov 2005 03:59:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02246 for ; Fri, 18 Nov 2005 03:58:55 -0500 (EST) Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed2NX-0007dp-HQ for xcon@ietf.org; Fri, 18 Nov 2005 04:17:56 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAI8xRU1017187; Fri, 18 Nov 2005 10:59:29 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Nov 2005 10:59:27 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 Nov 2005 10:59:27 +0200 Received: from 172.21.34.145 ([172.21.34.145]) by esebe105.NOE.Nokia.com ([172.21.143.53]) with Microsoft Exchange Server HTTP-DAV ; Fri, 18 Nov 2005 08:59:26 +0000 Received: from hed034-145.research.nokia.com by esebe105.noe.nokia.com; 18 Nov 2005 10:59:26 +0200 Subject: RE: [XCON] Call for Consensus and Discussion: Data Model From: Jari Urpalainen To: ext Orit Levin In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 18 Nov 2005 10:59:26 +0200 Message-Id: <1132304366.25660.86.camel@hed034-145.research.nokia.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-OriginalArrivalTime: 18 Nov 2005 08:59:27.0274 (UTC) FILETIME=[612250A0:01C5EC1E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: Adam Roach , XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org On Thu, 2005-11-17 at 13:00 -0800, ext Orit Levin wrote: > First, I would like to restate my support for the concensus below. > > One of the major aspects to be addressed in the XCON data model is how > to make it extensible by both standard and vendor specific content. > > I started this discussion in > http://www.ietf.org/internet-drafts/draft-levin-xcon-conference-package- > ext-00.txt and presented the requirements in > http://www.softarmor.com/xcon/meets/ietf64/slides/levin-conf-pkg-ext-iet > f64.ppt. During the meeting Jari expressed his preference to just using > RelaxNG for XCON instead, but this would require getting approval from > the XML directorate and other interested parties. Jari also volunteered > to talk to the "XML directorate" regarding this topic. > > My preference would be to still take the precautions and RECOMMEND the > simple conventions suggested in > http://www.ietf.org/internet-drafts/draft-levin-xcon-conference-package- > ext-00.txt in order to be compatible with the strict standard-compliant > XML compilers and not just RelaxNG. > > In any case, I suggest that we incorporate the alternatives into the > common data draft and continue investigating both directions. > > Thanks a lot, > Orit. E.g. in Simple WG W3C Schema has been used extensively. Also it has been popular to add extensibility to the content models typically with e.g. ... ... Then you want to define an extension to the base spec, so that you'll place an optional new element to that extension position, i.e. you'd want to make a forwards and backwards compatible schema: ... ... But you aren't allowed to do this as this violates the infamous Unique Particle Attribution (UPA) constraint in Appendix H of the Schema spec. There are several really ugly hacks to overcome this issue. So the pragmatic model is just to define a new element with a new schema and say "this element extends the element in the base spec. Once you end up having many extension points the possible combinations explode and w3c schema validation becomes more and more useless: it can not detect wrongly positioned elements, root element can be any of the global elements of the schemas, you can add undefined elements using the namespaces of the extension schemas etc. Furthermore, UPA constraint mandates to add new namespaces, I'd much prefer a situation where the same namespace is re-used so that instance docs are much simpler to us stupid implementers etc. Also the structures spec is so difficult to understand that at least I'm unable to get almost anything out of it. So why all this complaining ? There's a tool that doesn't have these problems (RELAX NG). Besides, it is imo also much easier to understand and use. Sure it ain't perfect either, but I'm frustrated because so many are facing these same W3C Schema issues all the time. So my preference is to use a tool that fits to the task at hand. Probably a comparison I-D of the features would help for WGs to decide what tools should they use, but personally I don't have doubts what's the best for pragmatic work (this includes even on-the-fly validations) thanks, Jari _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Nov 18 08:55:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed6iV-0001pO-Al; Fri, 18 Nov 2005 08:55:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed6iS-0001om-Ne for xcon@megatron.ietf.org; Fri, 18 Nov 2005 08:55:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18949 for ; Fri, 18 Nov 2005 08:55:13 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed70E-0000hX-Cc for xcon@ietf.org; Fri, 18 Nov 2005 09:14:16 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3321D4F0053; Fri, 18 Nov 2005 14:55:23 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 14:55:04 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Nov 2005 14:55:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Call for Consensus and Discussion: Data Model Date: Fri, 18 Nov 2005 14:55:03 +0100 Message-ID: Thread-Topic: [XCON] Call for Consensus and Discussion: Data Model Thread-Index: AcXsHi4h9MEOTFxkQHKnIIMTwivXiAAKABIg From: "Oscar Novo (JO/LMF)" To: "Jari Urpalainen" , "ext Orit Levin" X-OriginalArrivalTime: 18 Nov 2005 13:55:04.0759 (UTC) FILETIME=[AD7FBC70:01C5EC47] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Cc: XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Jari, Personally, I don=B4t have any problem to use RELAX NG or XML Schema but = you need the approval from the XML directorate. Meanwhile, we have to = use some tool to define our documents and we can not wait till the XML = directorate change their opinion because the XCON WG has been behind = shedule for a long time.=20 Thanks, Oscar -----Original Message----- From: Jari Urpalainen [mailto:jari.urpalainen@nokia.com]=20 Sent: 18. marraskuuta 2005 10:59 To: ext Orit Levin Cc: Oscar Novo (JO/LMF); Adam Roach; XCON-IETF Subject: RE: [XCON] Call for Consensus and Discussion: Data Model On Thu, 2005-11-17 at 13:00 -0800, ext Orit Levin wrote: > First, I would like to restate my support for the concensus below. > =20 > One of the major aspects to be addressed in the XCON data model is how = > to make it extensible by both standard and vendor specific content. >=20 > I started this discussion in > http://www.ietf.org/internet-drafts/draft-levin-xcon-conference-packag > e- ext-00.txt and presented the requirements in=20 > http://www.softarmor.com/xcon/meets/ietf64/slides/levin-conf-pkg-ext-i > et f64.ppt. During the meeting Jari expressed his preference to just=20 > using RelaxNG for XCON instead, but this would require getting=20 > approval from the XML directorate and other interested parties. Jari=20 > also volunteered to talk to the "XML directorate" regarding this=20 > topic. >=20 > My preference would be to still take the precautions and RECOMMEND the = > simple conventions suggested in > http://www.ietf.org/internet-drafts/draft-levin-xcon-conference-packag > e- ext-00.txt in order to be compatible with the strict=20 > standard-compliant XML compilers and not just RelaxNG. >=20 > In any case, I suggest that we incorporate the alternatives into the=20 > common data draft and continue investigating both directions. >=20 > Thanks a lot, > Orit. E.g. in Simple WG W3C Schema has been used extensively. Also it has been = popular to add extensibility to the content models typically with = e.g. ... =20 ...=20 Then you want to define an extension to the base spec, so that you'll = place an optional new element to that extension position, i.e. you'd = want to make a forwards and backwards compatible schema: ... =20 ...=20 But you aren't allowed to do this as this violates the infamous Unique = Particle Attribution (UPA) constraint in Appendix H of the Schema spec. There are several really ugly hacks to overcome this issue. So the pragmatic model is just to define a new element with a new schema = and say "this element extends the element in the base spec. Once you end up having many extension points the possible combinations = explode and w3c schema validation becomes more and more useless: it can = not detect wrongly positioned elements, root element can be any of the = global elements of the schemas, you can add undefined elements using the = namespaces of the extension schemas etc. Furthermore, UPA constraint = mandates to add new namespaces, I'd much prefer a situation where the = same namespace is re-used so that instance docs are much simpler to us = stupid implementers etc. Also the structures spec is so difficult to = understand that at least I'm unable to get almost anything out of it. So why all this complaining ? There's a tool that doesn't have these = problems (RELAX NG). Besides, it is imo also much easier to understand = and use. Sure it ain't perfect either, but I'm frustrated because so = many are facing these same W3C Schema issues all the time. So my = preference is to use a tool that fits to the task at hand.=20 Probably a comparison I-D of the features would help for WGs to decide = what tools should they use, but personally I don't have doubts what's = the best for pragmatic work (this includes even on-the-fly validations) thanks, Jari _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Nov 21 16:29:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeJEK-0003JT-Vx; Mon, 21 Nov 2005 16:29:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeJEJ-0003JO-Ut for xcon@megatron.ietf.org; Mon, 21 Nov 2005 16:29:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14484 for ; Mon, 21 Nov 2005 16:29:02 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeJWo-0003AJ-CP for xcon@ietf.org; Mon, 21 Nov 2005 16:48:49 -0500 Received: from [172.17.2.251] (dsl001-129-069.dfw1.dsl.speakeasy.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jALLTGvW078941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Nov 2005 15:29:19 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <43823C2B.5030807@nostrum.com> Date: Mon, 21 Nov 2005 15:29:15 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: XCON-IETF X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Subject: [XCON] Conference Control: Path Forward X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org [as chair] In Vancouver, the XCON chairs outlined a process by which we would attempt to meet our proposed milestones. This message summarizes that process, as amended by the input we received from the XCON participants. 1. Proposals for candidates for the Conference Control Protocol (CCP) must be submitted in internet-draft format no later than December 31st, 2005. The draft does not need to be complete; however, there must be sufficient detail to make clear how the proposed protocol would be used to modify information in both the Common Conference Information and Conference Template. (See draft-ietf-xcon-framework for definitions). 2. All protocols to be considered additionally need a brief message from an author and/or proponent of the corresponding draft that explains the design decisions taken in the design of the protocol, as well as a summary of strengths and drawbacks of the approach. Such proponents should contact the XCON chairs to coordinate. * Such proponents should discuss implementation lessons, if available, around using their proposed protocol to modify the Common Conference Information. * Separately, such proponents should additionally discuss implementation lessons, if available, around using their proposed protocol to modify the Conference Template. 3. Starting in early January, the chairs will call for discussion on the mailing list to gauge the overall direction the working group wishes to proceed. 4. Between now and January, interested parties should discuss their requirements around the CCP on the mailing list. These discussions should assist in coming to consensus on the CCP that XCON will use. Hopefully, the result of the January discussions will resolve to a single approach (either by selection of one of the proposals or by combining one or more of them into a unified proposal). /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Nov 28 17:21:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgrNj-0005LZ-NQ; Mon, 28 Nov 2005 17:21:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgrNi-0005LI-D2 for xcon@megatron.ietf.org; Mon, 28 Nov 2005 17:21:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01184 for ; Mon, 28 Nov 2005 17:21:09 -0500 (EST) Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egrhf-0007Sy-AP for xcon@ietf.org; Mon, 28 Nov 2005 17:42:31 -0500 Received: from [172.17.2.251] ([172.17.2.251]) (authenticated bits=0) by vicuna.estacado.net (8.13.3/8.13.3) with ESMTP id jASMLnie088627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Nov 2005 16:21:50 -0600 (CST) (envelope-from adam@estacado.net) Message-ID: <438B82FE.4080806@estacado.net> Date: Mon, 28 Nov 2005 16:21:50 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach Subject: URGENT REMINDER: [XCON] Conference Control: Path Forward References: <43823C2B.5030807@nostrum.com> In-Reply-To: <43823C2B.5030807@nostrum.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org [as chair] If anyone in the working group cares about the protocol we end up selecting for conference control -- or, indeed, finishing our work at all -- they are strongly advised to participate in this conversation. If we can't get any participation around our deliverables, we really have no choice but to shut the working group down. /a Adam Roach wrote: > [as chair] > > In Vancouver, the XCON chairs outlined a process by which we would > attempt to meet our proposed milestones. This message summarizes that > process, as amended by the input we received from the XCON participants. > > 1. Proposals for candidates for the Conference Control Protocol (CCP) > must be submitted in internet-draft format no later than December > 31st, 2005. The draft does not need to be complete; however, there > must be sufficient detail to make clear how the proposed protocol > would be used to modify information in both the Common Conference > Information and Conference Template. (See > draft-ietf-xcon-framework for definitions). > > 2. All protocols to be considered additionally need a brief message > from an author and/or proponent of the corresponding draft that > explains the design decisions taken in the design of the protocol, > as well as a summary of strengths and drawbacks of the approach. > Such proponents should contact the XCON chairs to coordinate. > * Such proponents should discuss implementation lessons, if > available, around using their proposed protocol to modify > the Common Conference Information. > * Separately, such proponents should additionally discuss > implementation lessons, if available, around using their > proposed protocol to modify the Conference Template. > > 3. Starting in early January, the chairs will call for discussion on > the mailing list to gauge the overall direction the working group > wishes to proceed. > > 4. Between now and January, interested parties should discuss their > requirements around the CCP on the mailing list. These discussions > should assist in coming to consensus on the CCP that XCON will use. > > Hopefully, the result of the January discussions will resolve to a > single approach (either by selection of one of the proposals or by > combining one or more of them into a unified proposal). > > /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 Mon Nov 28 23:14:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egwt7-0005tq-D5; Mon, 28 Nov 2005 23:14:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egwt5-0005pC-Un for xcon@megatron.ietf.org; Mon, 28 Nov 2005 23:14:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06264 for ; Mon, 28 Nov 2005 23:13:54 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgxD5-0001tw-R7 for xcon@ietf.org; Mon, 28 Nov 2005 23:35:20 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id jAT4AnU16472; Mon, 28 Nov 2005 23:10:49 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: URGENT REMINDER: [XCON] Conference Control: Path Forward Date: Mon, 28 Nov 2005 22:13:57 -0600 Message-ID: Thread-Topic: URGENT REMINDER: [XCON] Conference Control: Path Forward Thread-Index: AcX0anBgXd1+pEyyQZ25IiTiPEVvhgAKQAmQ From: "Mary Barnes" To: "Adam Roach" , "Adam Roach" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Cc: XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Sorry, I had read the previous email as merely summarizing the WG discussion in Vancouver, however, upon re-reading I can see the need for discussion. I agree with the general approach for the way forward. I have a process question around Item 2, as to whether there's a deadline for that summary. Were you expecting that summary prior to Dec 31st (i.e. are you wanting folks to let you know right now whether they'll be submitting proposals for that deadline)? Or is that something that can be submitted around the same time as the protocol is submitted for discussion? =20 My understanding is that we have 2 fairly concrete proposals on the table: CCCP and CSCP, with a potential 3rd protocol based on SOAP that some of us are interested in evolving, provided we can eek out the time to put something more detailed together. =20 I'll start a separate thread to discuss in more detail some requirements for the protocol. =20 Mary -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Adam Roach Sent: Monday, November 28, 2005 4:22 PM To: Adam Roach Cc: XCON-IETF Subject: URGENT REMINDER: [XCON] Conference Control: Path Forward [as chair] If anyone in the working group cares about the protocol we end up=20 selecting for conference control -- or, indeed, finishing our work at=20 all -- they are strongly advised to participate in this conversation. If we can't get any participation around our deliverables, we really have=20 no choice but to shut the working group down. /a Adam Roach wrote: > [as chair] > > In Vancouver, the XCON chairs outlined a process by which we would=20 > attempt to meet our proposed milestones. This message summarizes that=20 > process, as amended by the input we received from the XCON participants. > > 1. Proposals for candidates for the Conference Control Protocol (CCP) > must be submitted in internet-draft format no later than December > 31st, 2005. The draft does not need to be complete; however, there > must be sufficient detail to make clear how the proposed protocol > would be used to modify information in both the Common Conference > Information and Conference Template. (See > draft-ietf-xcon-framework for definitions). > > 2. All protocols to be considered additionally need a brief message > from an author and/or proponent of the corresponding draft that > explains the design decisions taken in the design of the protocol, > as well as a summary of strengths and drawbacks of the approach. > Such proponents should contact the XCON chairs to coordinate. > * Such proponents should discuss implementation lessons, if > available, around using their proposed protocol to modify > the Common Conference Information. > * Separately, such proponents should additionally discuss > implementation lessons, if available, around using their > proposed protocol to modify the Conference Template. > > 3. Starting in early January, the chairs will call for discussion on > the mailing list to gauge the overall direction the working group > wishes to proceed. > > 4. Between now and January, interested parties should discuss their > requirements around the CCP on the mailing list. These discussions > should assist in coming to consensus on the CCP that XCON will use. > > Hopefully, the result of the January discussions will resolve to a=20 > single approach (either by selection of one of the proposals or by=20 > combining one or more of them into a unified proposal). > > /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 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Nov 29 01:16:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgynM-0000Fv-5W; Tue, 29 Nov 2005 01:16:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgynL-0000Ed-9f for xcon@megatron.ietf.org; Tue, 29 Nov 2005 01:16:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18333 for ; Tue, 29 Nov 2005 01:16:07 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egz7L-0005kn-MH for xcon@ietf.org; Tue, 29 Nov 2005 01:37:33 -0500 Received: from [192.168.0.102] (ppp-70-128-140-54.dsl.rcsntx.swbell.net [70.128.140.54]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id jAT6GbIc091314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Nov 2005 00:16:39 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <438C0128.3000604@nostrum.com> Date: Tue, 29 Nov 2005 01:20:08 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mary Barnes Subject: Re: URGENT REMINDER: [XCON] Conference Control: Path Forward References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.128.140.54 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: Adam Roach , XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Mary Barnes wrote: >I have a process question around Item 2, as to whether there's a deadline >for that summary. Were you expecting that summary prior to Dec 31st >(i.e. are you wanting folks to let you know right now whether they'll be >submitting proposals for that deadline)? Or is that something that can >be submitted around the same time as the protocol is submitted for >discussion? > > I think submitting something around the same time as the proposal is appropriate. Ideally, the single proponent for each proposal should send an email to the chairs so we'll know who to expect information from (and who to remind if necessary) near the end of the year. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Nov 29 01:52:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgzLZ-0002ig-2A; Tue, 29 Nov 2005 01:52:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgzLY-0002ib-7l for xcon@megatron.ietf.org; Tue, 29 Nov 2005 01:52:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22008 for ; Tue, 29 Nov 2005 01:51:27 -0500 (EST) 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 1EgzfY-0006wo-Fx for xcon@ietf.org; Tue, 29 Nov 2005 02:12:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: [XCON] Call for Consensus and Discussion: Data Model MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Nov 2005 08:53:32 +0200 Message-ID: <144ED8561CE90C41A3E5908EDECE315C02C09F9C@IsrExch01.israel.polycom.com> Thread-Topic: [XCON] Call for Consensus and Discussion: Data Model Thread-Index: AcXrDusYTEtaXudcTdWVXYXWHE4kEwJPv0kw From: "Even, Roni" To: "XCON-IETF" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org As the one who made comments about the usage of the sipping-conferencing-package, I would like to clarify my comments. The XCON conferencing framework draft in section 5 "In a system based on this conferencing framework, the same conference object type is used for representation of a conference during different stages of a conference, such as expressing conferencing system capabilities, reserving conferencing resources or reflecting the state of ongoing conferences.". On the other hand the event package represents just the state of on going conference. The event package does not address the conference capabilities for example can the conference be extended, what is the mixing policy, can non specified users join the conference or is the conference access allowed only to users pre-defined by the creator.=20 This is why I am not sure that the conference-info by itself or the extension suggested by Orit will be enough since the event package should just conveying the current state. Roni Even -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Adam Roach Sent: Thursday, November 17, 2005 2:32 AM To: XCON-IETF Subject: [XCON] Call for Consensus and Discussion: Data Model [as chair] In Vancouver, there was considerable discussion around the XCON data model. There seemed to be considerable consensus around the position that we would use the XML schema defined in draft-ietf-sipping-conference-package-12 as the basis for the data model used in XCON. There was also a sentiment expressed that this schema needs additional elements added so that it can express all the information relevant to the data model we are defining in XCON.=20 draft-novo-xcon-common-data-model-00 purports to be a starting point for defining such additional elements. This message is intended to (a) verify the consensus to use the conference event package as a starting point, and (b) spur discussion around what additional data items are necessary to make it complete for XCON's purposes. /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 Tue Nov 29 05:39:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh2tv-0005BE-Hs; Tue, 29 Nov 2005 05:39:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh2tu-0005Am-DB for xcon@megatron.ietf.org; Tue, 29 Nov 2005 05:39:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15158 for ; Tue, 29 Nov 2005 05:39:09 -0500 (EST) Received: from m1.informatik.uni-bremen.de ([134.102.201.18] helo=informatik.uni-bremen.de ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh3Dv-0006EI-S4 for xcon@ietf.org; Tue, 29 Nov 2005 06:00:38 -0500 Received: from [127.0.0.1] (m2.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:343a]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id jATAdYeE019638; Tue, 29 Nov 2005 11:39:39 +0100 (CET) Message-ID: <438C2F6D.3010600@netlab.hut.fi> Date: Tue, 29 Nov 2005 12:37:33 +0200 From: Joerg Ott User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mary Barnes Subject: Re: URGENT REMINDER: [XCON] Conference Control: Path Forward References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: 7bit Cc: Adam Roach , Adam Roach , XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org As for the process: this seems reasonable. The only thing possibly missing is a measure on the actual support and review the proposals and ultimately the WG document will get so that discussions and a decision will be well-founded (item 3 and beyond). This is just in reaction to the lack of response to your last email (which, like Mary, I also read as summary not requiring action). We have tried conference control for a few times in the IETF. This time, finally, I thought there should be sufficient motivation... And somewhat off-topic: Can we please rename CCCP now or in the final version (if it comes to one)? People should be aware that CCCP stands for a distributed (multicast-based) conference control protocol developed in the mid 1990s in the context of Mbone applications (published at SIGCOMM 1995). Since this is a totally different approach in the same area, we should not re-use the acronym (or at least pretend that we have been doing our review of past work in that space and put a reference and a corresponding statement into the draft). (Some time back I thought CCCP was merely kept as the draft name rather than protocol name; this is why I did not speak up earlier.) Cheers, Joerg > Sorry, I had read the previous email as merely summarizing the WG > discussion in Vancouver, however, upon re-reading I can see the need for > discussion. I agree with the general approach for the way forward. I > have a process question around Item 2, as to whether there's a deadline > for that summary. Were you expecting that summary prior to Dec 31st > (i.e. are you wanting folks to let you know right now whether they'll be > submitting proposals for that deadline)? Or is that something that can > be submitted around the same time as the protocol is submitted for > discussion? > > My understanding is that we have 2 fairly concrete proposals on the > table: CCCP and CSCP, with a potential 3rd protocol based on SOAP that > some of us are interested in evolving, provided we can eek out the time > to put something more detailed together. > > I'll start a separate thread to discuss in more detail some requirements > for the protocol. > > Mary > > -----Original Message----- > From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of > Adam Roach > Sent: Monday, November 28, 2005 4:22 PM > To: Adam Roach > Cc: XCON-IETF > Subject: URGENT REMINDER: [XCON] Conference Control: Path Forward > > > [as chair] > > If anyone in the working group cares about the protocol we end up > selecting for conference control -- or, indeed, finishing our work at > all -- they are strongly advised to participate in this conversation. If > > we can't get any participation around our deliverables, we really have > no choice but to shut the working group down. > > /a > > Adam Roach wrote: > > >>[as chair] >> >>In Vancouver, the XCON chairs outlined a process by which we would >>attempt to meet our proposed milestones. This message summarizes that >>process, as amended by the input we received from the XCON > > participants. > >> 1. Proposals for candidates for the Conference Control Protocol > > (CCP) > >> must be submitted in internet-draft format no later than December >> 31st, 2005. The draft does not need to be complete; however, > > there > >> must be sufficient detail to make clear how the proposed protocol >> would be used to modify information in both the Common Conference >> Information and Conference Template. (See >> draft-ietf-xcon-framework for definitions). >> >> 2. All protocols to be considered additionally need a brief message >> from an author and/or proponent of the corresponding draft that >> explains the design decisions taken in the design of the > > protocol, > >> as well as a summary of strengths and drawbacks of the approach. >> Such proponents should contact the XCON chairs to coordinate. >> * Such proponents should discuss implementation lessons, if >> available, around using their proposed protocol to modify >> the Common Conference Information. >> * Separately, such proponents should additionally discuss >> implementation lessons, if available, around using their >> proposed protocol to modify the Conference Template. >> >> 3. Starting in early January, the chairs will call for discussion on >> the mailing list to gauge the overall direction the working group >> wishes to proceed. >> >> 4. Between now and January, interested parties should discuss their >> requirements around the CCP on the mailing list. These > > discussions > >> should assist in coming to consensus on the CCP that XCON will > > use. > >>Hopefully, the result of the January discussions will resolve to a >>single approach (either by selection of one of the proposals or by >>combining one or more of them into a unified proposal). >> >>/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 > > > _______________________________________________ > 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 Tue Nov 29 08:10:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh5Fj-00023x-UC; Tue, 29 Nov 2005 08:10:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh5Fh-00023h-K8 for xcon@megatron.ietf.org; Tue, 29 Nov 2005 08:10:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01572 for ; Tue, 29 Nov 2005 08:09:49 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh5Zm-0002Zo-5r for xcon@ietf.org; Tue, 29 Nov 2005 08:31:18 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Eh5FR-000545-K9; Tue, 29 Nov 2005 07:10:19 -0600 From: "Brian Rosen" To: "'Even, Roni'" , "'XCON-IETF'" Subject: RE: [XCON] Call for Consensus and Discussion: Data Model Date: Tue, 29 Nov 2005 08:09:07 -0500 Message-ID: <020d01c5f4e6$17e20130$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <144ED8561CE90C41A3E5908EDECE315C02C09F9C@IsrExch01.israel.polycom.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcXrDusYTEtaXudcTdWVXYXWHE4kEwJPv0kwACUxk5A= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dx28.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-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org As one who frequently opposes more than one way to do the same thing, I'd like to explore this subject a little. I hope we indeed do have consensus that there is an object, and the object represents the state of the conference. I don't hear anyone disputing that. We are discussing a protocol that directly manipulates this object. I hope that doing something like altering the mixing policy is done by the protocol, and that's the only way to do it. I do think we all agree that we need mechanisms for asynchronous notification of various kinds of conference events, and an event package is the way to do that if SIP is the protocol you are using to contact the conference server. I would not want our new conference control protocol to have its own asynchronous event notification mechanism. That leaves a gray area. The current conference package provides a way to "read" the current conference state. Another way to do that is to use the conference control package to read the object. This leads to the design decision of what is the way to determine the state of the conference: tickle the asynchronous event package to send you the conference object and look at it, or read it using the conference control package? After giving this some thought, my conclusion is that the conference package as it is presently constituted should just remain as it is. Any actual new asynchronous events we need should be defined in a new package that would only be implemented by endpoints that needed it and reading the conference object should be accomplished with the protocol. Let's take a specific example: what is the current state of my master volume control? Since I set it with the conference control protocol, if I want to get its current value, I think I should use the protocol to get it. On the other hand, if I want to know when Mary is in a sidebar (so that I could, for example, make the fact that she is probably not paying attention to the main conference visible by some kind of indicator on my screen), then I probably want an event package that gives me a way to find that out. It may well be that the event notification includes all or part of the conference object, so I do get some state with the event. That's okay, and I think it's a "part of the object", not the whole thing. I think that event is part of a new package, and is not part of, or an extension to, the current package. I think the entire object is too big to be sent on every event, and I don't want a simple endpoint to have to deal with all manner of new events we may decide we need. The way I see it, if you implement the control protocol, you probably will implement the event package that goes with it. Templates may define new state, and thus possibly new events. It's another design decision on how to implement a new event: define a new package with just the new events, define a new package which includes the events associated with the "common" part, or have an extension mechanism for an event package. I think the latter is a bad idea. As one who sees the template as including the common part, I'd probably be consistent and have a template defined package include any common events. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Even, Roni Sent: Tuesday, November 29, 2005 1:54 AM To: XCON-IETF Subject: RE: [XCON] Call for Consensus and Discussion: Data Model As the one who made comments about the usage of the sipping-conferencing-package, I would like to clarify my comments. The XCON conferencing framework draft in section 5 "In a system based on this conferencing framework, the same conference object type is used for representation of a conference during different stages of a conference, such as expressing conferencing system capabilities, reserving conferencing resources or reflecting the state of ongoing conferences.". On the other hand the event package represents just the state of on going conference. The event package does not address the conference capabilities for example can the conference be extended, what is the mixing policy, can non specified users join the conference or is the conference access allowed only to users pre-defined by the creator. This is why I am not sure that the conference-info by itself or the extension suggested by Orit will be enough since the event package should just conveying the current state. Roni Even -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Adam Roach Sent: Thursday, November 17, 2005 2:32 AM To: XCON-IETF Subject: [XCON] Call for Consensus and Discussion: Data Model [as chair] In Vancouver, there was considerable discussion around the XCON data model. There seemed to be considerable consensus around the position that we would use the XML schema defined in draft-ietf-sipping-conference-package-12 as the basis for the data model used in XCON. There was also a sentiment expressed that this schema needs additional elements added so that it can express all the information relevant to the data model we are defining in XCON. draft-novo-xcon-common-data-model-00 purports to be a starting point for defining such additional elements. This message is intended to (a) verify the consensus to use the conference event package as a starting point, and (b) spur discussion around what additional data items are necessary to make it complete for XCON's purposes. /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 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Nov 29 10:12:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh79V-0005vD-6E; Tue, 29 Nov 2005 10:12:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh79T-0005ss-Np for xcon@megatron.ietf.org; Tue, 29 Nov 2005 10:12:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17745 for ; Tue, 29 Nov 2005 10:11:30 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh7TR-0006zh-Lf for xcon@ietf.org; Tue, 29 Nov 2005 10:33:01 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 00EA84F0746; Tue, 29 Nov 2005 16:12:00 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Nov 2005 16:10:33 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 29 Nov 2005 16:10:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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] Call for Consensus and Discussion: Data Model Date: Tue, 29 Nov 2005 16:10:32 +0100 Message-ID: Thread-Topic: [XCON] Call for Consensus and Discussion: Data Model Thread-Index: AcXrDusYTEtaXudcTdWVXYXWHE4kEwJPv0kwACUxk5AABJ1lMA== From: "Oscar Novo (JO/LMF)" To: , "Even, Roni" , "XCON-IETF" X-OriginalArrivalTime: 29 Nov 2005 15:10:33.0173 (UTC) FILETIME=[0B302050:01C5F4F7] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Completely Agree with Brian. The current conference event package represents just the state of the conference. So, the system notify me the state of the conference using the event notification package every time there is an important change in the state of the conference (new user join the system...).=20 Note that the "SIP Event Package for Conference State" already includes the posibility to send a "part of the conference object" state (Section 4.4 Partial Notifications Mechanism).=20 The conference control protocol we choose should have a mechanism to query the capabilities of the system (mixing policy, can non specified users join the conference or is the conference access allowed only to users pre-defined by the creator and so on). Oscar -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Brian Rosen Sent: 29. marraskuuta 2005 15:09 To: 'Even, Roni'; 'XCON-IETF' Subject: RE: [XCON] Call for Consensus and Discussion: Data Model As one who frequently opposes more than one way to do the same thing, I'd like to explore this subject a little. I hope we indeed do have consensus that there is an object, and the object represents the state of the conference. I don't hear anyone disputing that. We are discussing a protocol that directly manipulates this object. I hope that doing something like altering the mixing policy is done by the protocol, and that's the only way to do it. I do think we all agree that we need mechanisms for asynchronous notification of various kinds of conference events, and an event package is the way to do that if SIP is the protocol you are using to contact the conference server. I would not want our new conference control protocol to have its own asynchronous event notification mechanism. That leaves a gray area. The current conference package provides a way to "read" the current conference state. Another way to do that is to use the conference control package to read the object. This leads to the design decision of what is the way to determine the state of the conference: tickle the asynchronous event package to send you the conference object and look at it, or read it using the conference control package? After giving this some thought, my conclusion is that the conference package as it is presently constituted should just remain as it is. Any actual new asynchronous events we need should be defined in a new package that would only be implemented by endpoints that needed it and reading the conference object should be accomplished with the protocol. Let's take a specific example: what is the current state of my master volume control? Since I set it with the conference control protocol, if I want to get its current value, I think I should use the protocol to get it. On the other hand, if I want to know when Mary is in a sidebar (so that I could, for example, make the fact that she is probably not paying attention to the main conference visible by some kind of indicator on my screen), then I probably want an event package that gives me a way to find that out. It may well be that the event notification includes all or part of the conference object, so I do get some state with the event. That's okay, and I think it's a "part of the object", not the whole thing. =20 I think that event is part of a new package, and is not part of, or an extension to, the current package. I think the entire object is too big to be sent on every event, and I don't want a simple endpoint to have to deal with all manner of new events we may decide we need. The way I see it, if you implement the control protocol, you probably will implement the event package that goes with it. Templates may define new state, and thus possibly new events. It's another design decision on how to implement a new event: define a new package with just the new events, define a new package which includes the events associated with the "common" part, or have an extension mechanism for an event package. I think the latter is a bad idea. As one who sees the template as including the common part, I'd probably be consistent and have a template defined package include any common events. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Even, Roni Sent: Tuesday, November 29, 2005 1:54 AM To: XCON-IETF Subject: RE: [XCON] Call for Consensus and Discussion: Data Model As the one who made comments about the usage of the sipping-conferencing-package, I would like to clarify my comments. The XCON conferencing framework draft in section 5 "In a system based on this conferencing framework, the same conference object type is used for representation of a conference during different stages of a conference, such as expressing conferencing system capabilities, reserving conferencing resources or reflecting the state of ongoing conferences.". On the other hand the event package represents just the state of on going conference. The event package does not address the conference capabilities for example can the conference be extended, what is the mixing policy, can non specified users join the conference or is the conference access allowed only to users pre-defined by the creator.=20 This is why I am not sure that the conference-info by itself or the extension suggested by Orit will be enough since the event package should just conveying the current state. Roni Even -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Adam Roach Sent: Thursday, November 17, 2005 2:32 AM To: XCON-IETF Subject: [XCON] Call for Consensus and Discussion: Data Model [as chair] In Vancouver, there was considerable discussion around the XCON data model. There seemed to be considerable consensus around the position that we would use the XML schema defined in draft-ietf-sipping-conference-package-12 as the basis for the data model used in XCON. There was also a sentiment expressed that this schema needs additional elements added so that it can express all the information relevant to the data model we are defining in XCON.=20 draft-novo-xcon-common-data-model-00 purports to be a starting point for defining such additional elements. This message is intended to (a) verify the consensus to use the conference event package as a starting point, and (b) spur discussion around what additional data items are necessary to make it complete for XCON's purposes. /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 _______________________________________________ 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 Tue Nov 29 11:55:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh8lP-0008Pl-R1; Tue, 29 Nov 2005 11:55:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh8lO-0008Pb-Nb for xcon@megatron.ietf.org; Tue, 29 Nov 2005 11:55:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02771 for ; Tue, 29 Nov 2005 11:54:45 -0500 (EST) Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh95V-0002kF-GO for xcon@ietf.org; Tue, 29 Nov 2005 12:16:17 -0500 Received: from [172.17.2.251] ([172.17.2.251]) (authenticated bits=0) by vicuna.estacado.net (8.13.3/8.13.3) with ESMTP id jATGtJZX092267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Nov 2005 10:55:20 -0600 (CST) (envelope-from adam@estacado.net) Message-ID: <438C87F7.8080007@estacado.net> Date: Tue, 29 Nov 2005 10:55:19 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Oscar Novo Subject: Re: [XCON] Call for Consensus and Discussion: Data Model References: In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by vicuna.estacado.net id jATGtJZX092267 X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Cc: Jari Urpalainen , Orit Levin , XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org [as chair] One important bit of feedback I've received from the XML directorate is=20 that they participate in an advisory capacity only. They don't issue=20 edicts. Working groups do not seek approval from them. The directorate=20 provides guidance when requested, but working groups are free to make=20 what they believe are the most technically appropriate choices for the=20 problems they need to solve. I'm still reviewing the directorate's feedback around the best way to=20 move forward with regards to our specific XML extensibility issue, and=20 will share their advice once I can process it into a coherent summary. /a Oscar Novo (JO/LMF) wrote: >Jari, > >Personally, I don=B4t have any problem to use RELAX NG or XML Schema but= you need the approval from the XML directorate. Meanwhile, we have to us= e some tool to define our documents and we can not wait till the XML dire= ctorate change their opinion because the XCON WG has been behind shedule = for a long time.=20 > >Thanks, > >Oscar > > >-----Original Message----- >From: Jari Urpalainen [mailto:jari.urpalainen@nokia.com]=20 >Sent: 18. marraskuuta 2005 10:59 >To: ext Orit Levin >Cc: Oscar Novo (JO/LMF); Adam Roach; XCON-IETF >Subject: RE: [XCON] Call for Consensus and Discussion: Data Model > >On Thu, 2005-11-17 at 13:00 -0800, ext Orit Levin wrote: > =20 > >>First, I would like to restate my support for the concensus below. >>=20 >>One of the major aspects to be addressed in the XCON data model is how=20 >>to make it extensible by both standard and vendor specific content. >> >>I started this discussion in >>http://www.ietf.org/internet-drafts/draft-levin-xcon-conference-packag >>e- ext-00.txt and presented the requirements in=20 >>http://www.softarmor.com/xcon/meets/ietf64/slides/levin-conf-pkg-ext-i >>et f64.ppt. During the meeting Jari expressed his preference to just=20 >>using RelaxNG for XCON instead, but this would require getting=20 >>approval from the XML directorate and other interested parties. Jari=20 >>also volunteered to talk to the "XML directorate" regarding this=20 >>topic. >> >>My preference would be to still take the precautions and RECOMMEND the=20 >>simple conventions suggested in >>http://www.ietf.org/internet-drafts/draft-levin-xcon-conference-packag >>e- ext-00.txt in order to be compatible with the strict=20 >>standard-compliant XML compilers and not just RelaxNG. >> >>In any case, I suggest that we incorporate the alternatives into the=20 >>common data draft and continue investigating both directions. >> >>Thanks a lot, >>Orit. >> =20 >> > >E.g. in Simple WG W3C Schema has been used extensively. Also it has been= popular to add extensibility to the content models typically with processContents=3D"lax"/> >e.g. >... > >processContents=3D"lax"/> =20 >...=20 >Then you want to define an extension to the base spec, so that you'll pl= ace an optional new element to that extension position, i.e. you'd want t= o make a forwards and backwards compatible schema: >... > > processContents=3D"lax"/> =20 >...=20 >But you aren't allowed to do this as this violates the infamous Unique P= article Attribution (UPA) constraint in Appendix H of the Schema spec. >There are several really ugly hacks to overcome this issue. > >So the pragmatic model is just to define a new element with a new schema= and say "this element extends the element in the base spec. >Once you end up having many extension points the possible combinations e= xplode and w3c schema validation becomes more and more useless: it can no= t detect wrongly positioned elements, root element can be any of the glob= al elements of the schemas, you can add undefined elements using the name= spaces of the extension schemas etc. Furthermore, UPA constraint mandates= to add new namespaces, I'd much prefer a situation where the same namesp= ace is re-used so that instance docs are much simpler to us stupid implem= enters etc. Also the structures spec is so difficult to understand that a= t least I'm unable to get almost anything out of it. > >So why all this complaining ? There's a tool that doesn't have these pro= blems (RELAX NG). Besides, it is imo also much easier to understand and u= se. Sure it ain't perfect either, but I'm frustrated because so many are = facing these same W3C Schema issues all the time. So my preference is to = use a tool that fits to the task at hand.=20 > >Probably a comparison I-D of the features would help for WGs to decide w= hat tools should they use, but personally I don't have doubts what's the = best for pragmatic work (this includes even on-the-fly validations) > >thanks, >Jari > >_______________________________________________ >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 Tue Nov 29 12:16:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh95P-0003aP-Tm; Tue, 29 Nov 2005 12:16:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh95O-0003Zz-0O for xcon@megatron.ietf.org; Tue, 29 Nov 2005 12:16:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06164 for ; Tue, 29 Nov 2005 12:15:23 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh9PU-0003kz-5B for xcon@ietf.org; Tue, 29 Nov 2005 12:36:56 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 29 Nov 2005 09:15:58 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Nov 2005 09:15:58 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Nov 2005 09:15:58 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Nov 2005 09:15:57 -0800 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: URGENT REMINDER: [XCON] Conference Control: Path Forward Date: Tue, 29 Nov 2005 09:15:56 -0800 Message-ID: Thread-Topic: URGENT REMINDER: [XCON] Conference Control: Path Forward thread-index: AcX00XdR1sdRsm2NQ0upbyIwYsfbvAANvgfQ From: "Sean Olson" To: "Joerg Ott" , "Mary Barnes" X-OriginalArrivalTime: 29 Nov 2005 17:15:57.0617 (UTC) FILETIME=[901B2A10:01C5F508] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: quoted-printable Cc: Orit Levin , Adam Roach , Adam Roach , XCON-IETF X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Renaming CCCP is not a bad idea.... We use C3P internally and I'm sure we could come up with a better name :-) -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Joerg Ott Sent: Tuesday, November 29, 2005 2:38 AM To: Mary Barnes Cc: Adam Roach; Adam Roach; XCON-IETF Subject: Re: URGENT REMINDER: [XCON] Conference Control: Path Forward As for the process: this seems reasonable. The only thing possibly missing is a measure on the actual support and review the proposals and ultimately the WG document will get so that discussions and a decision will be well-founded (item 3 and beyond). This is just in reaction to the lack of response to your last email (which, like Mary, I also read as summary not requiring action). We have tried conference control for a few times in the IETF. This time, finally, I thought there should be sufficient motivation... And somewhat off-topic: Can we please rename CCCP now or in the final version (if it comes to one)? People should be aware that CCCP stands for a distributed (multicast-based) conference control protocol developed in the mid 1990s in the context of Mbone applications (published at SIGCOMM 1995). Since this is a totally different approach in the same area, we should not re-use the acronym (or at least pretend that we have been doing our review of past work in that space and put a reference and a corresponding statement into the draft). (Some time back I thought CCCP was merely kept as the draft name rather than protocol name; this is why I did not speak up earlier.) Cheers, Joerg > Sorry, I had read the previous email as merely summarizing the WG=20 > discussion in Vancouver, however, upon re-reading I can see the need=20 > for discussion. I agree with the general approach for the way=20 > forward. I have a process question around Item 2, as to whether=20 > there's a deadline for that summary. Were you expecting that summary=20 > prior to Dec 31st (i.e. are you wanting folks to let you know right=20 > now whether they'll be submitting proposals for that deadline)? Or is > that something that can be submitted around the same time as the=20 > protocol is submitted for discussion? >=20 > My understanding is that we have 2 fairly concrete proposals on the > table: CCCP and CSCP, with a potential 3rd protocol based on SOAP that > some of us are interested in evolving, provided we can eek out the time > to put something more detailed together. =20 >=20 > I'll start a separate thread to discuss in more detail some=20 > requirements for the protocol. >=20 > Mary >=20 > -----Original Message----- > From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf=20 > Of Adam Roach > Sent: Monday, November 28, 2005 4:22 PM > To: Adam Roach > Cc: XCON-IETF > Subject: URGENT REMINDER: [XCON] Conference Control: Path Forward >=20 >=20 > [as chair] >=20 > If anyone in the working group cares about the protocol we end up=20 > selecting for conference control -- or, indeed, finishing our work at=20 > all -- they are strongly advised to participate in this conversation.=20 > If >=20 > we can't get any participation around our deliverables, we really have > no choice but to shut the working group down. >=20 > /a >=20 > Adam Roach wrote: >=20 >=20 >>[as chair] >> >>In Vancouver, the XCON chairs outlined a process by which we would=20 >>attempt to meet our proposed milestones. This message summarizes that=20 >>process, as amended by the input we received from the XCON >=20 > participants. >=20 >> 1. Proposals for candidates for the Conference Control Protocol >=20 > (CCP) >=20 >> must be submitted in internet-draft format no later than December >> 31st, 2005. The draft does not need to be complete; however, >=20 > there >=20 >> must be sufficient detail to make clear how the proposed protocol >> would be used to modify information in both the Common Conference >> Information and Conference Template. (See >> draft-ietf-xcon-framework for definitions). >> >> 2. All protocols to be considered additionally need a brief message >> from an author and/or proponent of the corresponding draft that >> explains the design decisions taken in the design of the >=20 > protocol, >=20 >> as well as a summary of strengths and drawbacks of the approach. >> Such proponents should contact the XCON chairs to coordinate. >> * Such proponents should discuss implementation lessons, if >> available, around using their proposed protocol to modify >> the Common Conference Information. >> * Separately, such proponents should additionally discuss >> implementation lessons, if available, around using their >> proposed protocol to modify the Conference Template. >> >> 3. Starting in early January, the chairs will call for discussion on >> the mailing list to gauge the overall direction the working group >> wishes to proceed. >> >> 4. Between now and January, interested parties should discuss their >> requirements around the CCP on the mailing list. These >=20 > discussions >=20 >> should assist in coming to consensus on the CCP that XCON will >=20 > use. >=20 >>Hopefully, the result of the January discussions will resolve to a=20 >>single approach (either by selection of one of the proposals or by=20 >>combining one or more of them into a unified proposal). >> >>/a >> >>_______________________________________________ >>XCON mailing list >>XCON@ietf.org >>https://www1.ietf.org/mailman/listinfo/xcon >> >=20 >=20 >=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 >=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 Wed Nov 30 05:25:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhP9r-0005wA-Sf; Wed, 30 Nov 2005 05:25:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhP9q-0005vS-OS for xcon@megatron.ietf.org; Wed, 30 Nov 2005 05:25:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25317 for ; Wed, 30 Nov 2005 05:25:05 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhPU5-00055V-QM for xcon@ietf.org; Wed, 30 Nov 2005 05:46:47 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B46314F000C for ; Wed, 30 Nov 2005 09:49:40 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Nov 2005 09:48:08 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Nov 2005 09:48:08 +0100 Received: from [131.160.36.33] (EGQAD00202EIE3F.lmf.ericsson.se [131.160.36.33]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3AC442930 for ; Wed, 30 Nov 2005 10:48:08 +0200 (EET) Message-ID: <438D6747.7070006@ericsson.com> Date: Wed, 30 Nov 2005 10:48:07 +0200 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: XCON Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Nov 2005 08:48:08.0491 (UTC) FILETIME=[C9813FB0:01C5F58A] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [XCON] New revision of BFCP drafts X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Folks, I have just submitted a new revision of the BFCP drafts. This revision should address the discuss comments we got during the IESG review. Until they appear in the archives, you can fetch the drafts from: http://users.piuha.net/gonzalo/temp/draft-ietf-xcon-bfcp-06.txt http://users.piuha.net/gonzalo/temp/draft-ietf-mmusic-sdp-bfcp-03.txt Cheers, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon