From xcon-bounces@ietf.org Thu Dec 01 15:50: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 1EhvOG-0000Y4-TV; Thu, 01 Dec 2005 15:50:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhvNW-00008y-G8; Thu, 01 Dec 2005 15:50:06 -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 PAA25910; Thu, 1 Dec 2005 15:49:17 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ehvi1-00084a-6D; Thu, 01 Dec 2005 16:11:18 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EhvNS-0006cY-2v; Thu, 01 Dec 2005 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 01 Dec 2005 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-bfcp-06.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : The Binary Floor Control Protocol (BFCP) Author(s) : G. Camarillo, et al. Filename : draft-ietf-xcon-bfcp-06.txt Pages : 63 Date : 2005-12-1 Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-bfcp-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-xcon-bfcp-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-xcon-bfcp-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-1121941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-bfcp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-bfcp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-1121941.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --NextPart-- From xcon-bounces@ietf.org Thu Dec 01 23:10: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 1Ei2G7-0000wf-PY; Thu, 01 Dec 2005 23:10:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei2G5-0000td-T4 for xcon@megatron.ietf.org; Thu, 01 Dec 2005 23:10: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 XAA04061 for ; Thu, 1 Dec 2005 23:10:07 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei2ac-0006SY-H5 for xcon@ietf.org; Thu, 01 Dec 2005 23:32:08 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jB24AMiP028409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Dec 2005 23:10:23 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id jB24AJG5007449; Thu, 1 Dec 2005 23:10:19 -0500 Message-ID: <438FC93A.6060102@cs.columbia.edu> Date: Thu, 01 Dec 2005 23:10:34 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: "Oscar Novo (JO/LMF)" Subject: Re: [XCON] Call for Consensus and Discussion: Data Model References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: "Even, Roni" , 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 From a practical perspective, you can indeed get a SUBSCRIBE to tickle a NOTIFY with the current state, but that seems far harder to program than a synchronous "query" mechanism. Thus, while this does duplicate mechanisms in a strict sense, the purpose and application is sufficiently different that this seems less harmful than the alternative. I would also argue that trying to develop an XCON-specific publish/subscribe/notify mechanism seems of dubious utility unless existing mechanisms are clearly incapable of handling the chore. One of the nicer aspects of re-using the event mechanism is that a lot of the tools, such as the privacy rules, can probably be drafted into service fairly easily. That way, we don't have to develop new XML to restrict who can get notified of conference events. Oscar Novo (JO/LMF) wrote: > 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...). > 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). > > 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 > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Dec 02 06:50:09 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 1Ei9QX-0005gg-Gs; Fri, 02 Dec 2005 06:50:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei9QV-0005gb-Of for xcon@megatron.ietf.org; Fri, 02 Dec 2005 06:50:08 -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 GAA11723 for ; Fri, 2 Dec 2005 06:49:20 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei9l6-0003kO-OV for xcon@ietf.org; Fri, 02 Dec 2005 07:11:30 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DDC6C199C; Fri, 2 Dec 2005 12:49:56 +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, 2 Dec 2005 12:46:55 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Dec 2005 12:46:54 +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, 2 Dec 2005 12:46:54 +0100 Message-ID: Thread-Topic: [XCON] Call for Consensus and Discussion: Data Model Thread-Index: AcX29iJbNO6NKL00SqCAp2CbFm/piwALE8CQ From: "Oscar Novo (JO/LMF)" To: "Henning Schulzrinne" X-OriginalArrivalTime: 02 Dec 2005 11:46:54.0969 (UTC) FILETIME=[17CF6690:01C5F736] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: "Even, Roni" , 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 Hi Henning, I don=B4t understand why you say the asynchronous query mechanism is = harder to program than the synchronous one. Could you please tell me in = what things one alternative is more difficult to program than the other? Oscar -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: 2. joulukuuta 2005 6:11 To: Oscar Novo (JO/LMF) Cc: br@brianrosen.net; Even, Roni; XCON-IETF Subject: Re: [XCON] Call for Consensus and Discussion: Data Model From a practical perspective, you can indeed get a SUBSCRIBE to tickle = a NOTIFY with the current state, but that seems far harder to program = than a synchronous "query" mechanism. Thus, while this does duplicate = mechanisms in a strict sense, the purpose and application is = sufficiently different that this seems less harmful than the = alternative. I would also argue that trying to develop an XCON-specific = publish/subscribe/notify mechanism seems of dubious utility unless = existing mechanisms are clearly incapable of handling the chore. One of = the nicer aspects of re-using the event mechanism is that a lot of the = tools, such as the privacy rules, can probably be drafted into service = fairly easily. That way, we don't have to develop new XML to restrict = who can get notified of conference events. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Dec 02 22:22:46 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 1EiNz4-0000d7-7l; Fri, 02 Dec 2005 22:22:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiNz2-0000ZJ-KH for xcon@megatron.ietf.org; Fri, 02 Dec 2005 22:22:44 -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 WAA08917 for ; Fri, 2 Dec 2005 22:21:55 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiOI8-0007m5-2L for xcon@ietf.org; Fri, 02 Dec 2005 22:42:29 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jB33KkiP001519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Dec 2005 22:20:47 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id jB33KjB7013389; Fri, 2 Dec 2005 22:20:46 -0500 Message-ID: <43910F0A.7080701@cs.columbia.edu> Date: Fri, 02 Dec 2005 22:20:42 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: "Oscar Novo (JO/LMF)" Subject: Re: [XCON] Call for Consensus and Discussion: Data Model References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cs.columbia.edu id jB33KkiP001519 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Oscar Novo (JO/LMF) wrote: > Hi Henning, >=20 > I don=B4t understand why you say the asynchronous query mechanism is > harder to program than the synchronous one. Could you please tell me > in what things one alternative is more difficult to program than the > other? Let me try to be more precise. A simple retrieval is programmed=20 something like (writing PHP-style) $var =3D query("http://example.com/whatever") or some similar construct (e.g., a SOAP library call), probably wrapped=20 in a 'catch' of some sort to deal with exceptional conditions such as a=20 timeout or network failure. For an asynchronous event mechanism, you'd have to do something like - issue the SUBSCRIBE request and deal with any errors; probably block=20 the thread if the value of the conference state is needed for further=20 computation - set up a call-back function that is invoked by the NOTIFY showing up=20 at some unspecified time in the future; associate the NOTIFY with the=20 pending request, as it may arrive on a completely different TCP or UDP=20 socket than the SUBSCRIBE - set up a timer so that the program doesn't freeze if the NOTIFY=20 doesn't show up after some reasonable amount of time; handle the time-out - unblock the thread in the call-back function and pass the results back=20 through some kind of shared thread variables This can all be done, but a simple request for a value becomes a fairly=20 substantial effort. Unfortunately, most languages seem to be ill-suited=20 for event-based programming. Henning _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Dec 09 22:38: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 1EkvZZ-0002HW-HF; Fri, 09 Dec 2005 22:38:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkvZX-0002Eh-LE; Fri, 09 Dec 2005 22:38:56 -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 WAA04884; Fri, 9 Dec 2005 22:38:01 -0500 (EST) Message-Id: <200512100338.WAA04884@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkvZq-0006Tj-8j; Fri, 09 Dec 2005 22:39:15 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EkvZJ-000Dxi-2e; Sat, 10 Dec 2005 03:38:41 +0000 To: hartmans-ietf@mit.edu, housley@vigilsec.com, hardie@qualcomm.com Date: Fri, 09 Dec 2005 19:38:41 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: da36eda0a3266ed30a56c496b15b76c7 Cc: mmusic@ietf.org, xcon@ietf.org, gonzalo.camarillo@ericsson.com, jon.peterson@neustar.biz Subject: [XCON] Progressing/Resolving the IESG Review of the BFCP specs X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mankin@psg.com List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Russ, Sam, Ted - Gonzalo has worked with you all, and spoke to the respective working groups. He has published revisions of the two specs which we believe should resolve your Discusses. Below are his comments on how. I've added a bit of commentary inline at a few places [AJM: ] Please let us know if you are able to clear now. Allison ------ Gonzalo writes --- I have put together new revisions of the BFCP drafts. They should address all the discusses in the ID tracker. http://www.ietf.org/internet-drafts/draft-ietf-xcon-bfcp-06.txt http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bfcp-03.txt Below I provide detailed answers to all the discusses: MMUSIC document: https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1786&filename=draft-ietf-mmusic-sdp-bfcp > Bill Fenner: > > Discuss [2005-09-01]: Port 20000 belongs to a protocol named 'DNP'; > should this example be from the dynamic port range (49152-65535) or > should bfcp have an IANA-assigned port number? The draft now uses ports in the dynamic port range. [AJM: Bill has cleared his Discuss] > Sam Hartman: > > Discuss [2005-08-31]: 1) Please replace the RFc 1750 reference with > RFC 4086. I have removed this reference as a result of removing the digest mechanism. > > 2) RFC 3548 is an informational RFC but is referenced as a normative > reference; RFC 3967 requires that this fact be mentioned in the last > call. It was not. This document needs to be last called again or > that reference changed. [Yes, I think this requirement is wrong; I > also understand the argument that we should follow our rules > consistently] I have removed this reference as a result of removing the digest mechanism. 3) I'm uncomfortable with this document being approved > before draft-ietf-mmusic-media-tls. Based on how this protocol > works, I suspect I have comments on that draft and depending on how > those comments are resolved, I think this draft may change. In > particular, I'm concerned about cases where the active open side of > the connection is the TLS server, the handling of the fingerprint > attribute and some concerns about asymmetry in this protocol. [AJM: Sam, draft-ietf-mmusic-media-tls is in IETF Last Call now - I am shepherding it. There will be no change initiated by the working group. We really need your comments on the draft - I solicited this from you again in a pre-IETF Last Call heads up. There's some time pressure because of outside bodies calling these protocols critical dependencies...] This draft normatively depends on the SDP TLS draft. So, in any case, it will need to wait for it before it can be published as an RFC. > > 4) This document is not aligned with the main BFCP document. First, > if the server can do active opens then section 6 and 14 of the BFCP > document need to discuss that. If the authors of this document > confirm that this document's behavior is correct, then I can amend my > BFCP discuss. I have clarified in the main BFCP spec that the floor control server can do active opens. > 5) The authentication handling in this document is not aligned with > BFCP. Section 8.1 of this document implies that digest is not used > if TLS is used; as discussed by section 9.2 of the BFCP document, > BFCP seems to support modes where both TLS and digest are used. > Similarly, section 8.2.1 only allows the digest shared secret to be > negotiated for tcp/bfcp not tcp/tls/bfcp. Again, I'm happy if these > document are aligned in either direction. I have removed the digest mechanism from the drafts. Now TLS is mandated. > 6) IT seems like the attributes discussed in section 8.1 need to be > integrity protected. However the security considerations does not > discuss this issue. I have removed the digest mechanism from the drafts. Now TLS is mandated. > Comment [2005-08-31]: I'm not sure I see a way that a server can > offer both a TLS and non-TLS stream using this media type. If > clients end up being required to support TLS tihs probably doesn't > matter. However it may be an issue if clients are not required to > support TLS. Perhaps I'm missing some information about how > offer/answer works. It definitely seems that two m lines would be > wrong because then a client could accept both of them. Now TLS is mandated. > > Russ Housley: > > Discuss [2005-09-01]: > > The value "c2hhcmVkLXNlY3JldA==" is used throughout the document as > the shared secret example value. While the ASCII string that was > encoded to make this value is cute, the string is not long enough. > RFC 2104 recommends that the key for HMAC-SHA-1 be 20 octets. I have removed the digest mechanism from the drafts. Now TLS is mandated. > I find the structure of section 8 very confusing. The authentication > of the SIP session that is used to perform an offer/answer exchange > is not clearly separated from the authentication of the BFCP protocol > entities. Further, if the 'fingerprint' attribute is not present, > what checks must be performed to ensure that the non-self-signed > certificate used for offer/answer exchange authentication belongs to > to the same party as the non-self-signed certificate used with > BFCP/TLS/TCP. This (and perhaps other related topics) belong in a > subsection that does not currently exist. With the removal of the digest mechanism everything should be clearer. > Section 8 says: >> >> Note that when mutual authentication is performed using TLS, it is >> not necessary to use this digest mechanism. >> > This does not agree with draft-ietf-xcon-bfcp-05, which says that the > digest mechanism must be used for the first message, even when TLS > is employed. > > Section 8.1 says: >> >> ... the certificate provided at the TLS-level must be signed by a >> certificate authority known to other party. >> > This is not quite correct, and the terminology does not align with > RFC 3280. I suggest: >> >> ... the certificate provided at the TLS-level MUST either be >> directly signed by one of the other party's trust anchors or be >> validated using a certification path that terminates at one of the >> other party's trust anchors. >> I have modifies the text according to your suggestion. > Also, a normative reference to RFC 3280 in this section is desirable. > Added. > > Section 8.2.1 says: >> >> The key-params field SHOULD use the 'inline' key method followed by >> a base64-encoded [6] unguessable secret [1]. >> > Please state the size of the shared secret value. I suspect that the > size depends on the selected integrity check function. The digest mechanism has been removed from the draft. > > Bert Wijnen: > > Comment [2005-09-01]: > > This document has a normative reference: [9] Levin, O. and G. > Camarillo, "The SDP (Session Description Protocol) Label Attribute", > draft-levin-mmmusic-sdp-media-label-00 (work in progress), July 2004. > > > and that document is an individual Internet-Draft, that also has > expired. So what impact does this have? I have updated the reference to draft-ietf-mmusic-sdp-media-label, which is a WG item. [AJM: and it is in the RFC Editor Queue] XCON document: https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1785&filename=draft-ietf-xcon-bfcp > Brian Carpenter: > > Comment [2005-09-01]: > Comment from John Loughney > > Intro says: > > The Requirements for Floor Control Protocol [10] list a set of > requirements that need to be met by floor control protocols. The > Binary Floor Control Protocol (BFCP), which is specified in this > document, meets these requirements. > > -> "Requirements for Floor Control Protocol" seems to have expired. > Awfully hard to know if the requirements have been met by this > protocol, if they've expired ... The requirements document has already been approved and is in the RFC Editor's queue at this point. > > Ted Hardie: > > Discuss [2005-08-31]: > The document says that it fulfills the requirements of > draft-ietf-xcon-floor-control-req, but the draft > has apparently expired. The requirements document has already been approved and is in the RFC Editor's queue at this point. > > The document describes the USER-URI field by saying: > > Text: this field contains the UTF-8 encoded URI of the user. > > Further details on what is meant by this seem required to get interoperable > use. The document > does note that it is returned in responses to User Query messages, but it is not > clear if it is > limited to a contact uri or has a broader applicability. I have clarified the scope of this attribute. > > Sam Hartman: > > Discuss [2005-08-31]: > Section 5.2 says: > > Length: this 8-bit field contains the length of the attribute in > > bytes, excluding any padding defined for specific attributes. > If I understand this text correctly, it means that a new attribute > can be defined with padding requirements such that the length byte > is not enough to find the end of this attribute and the beginning > of the next attribute because the padding is not included in the > length. This seems against the goal of having extensible attributes. All the attributes are32-bit aligned. Therefore, it is always possible to find the next attribute. > Section 5.2.7 indicates that the length of the DIGEST attribute > payload is always 24 bytes. This seems to be composed of: > header = 2 bytes > algorithm = 1 byte > digest = 20 bytes (for HMAC-SHA-1) > padding = 2 bytes > This adds up to 25 bytes. Please correct. Also, the size of > this attribute should not be constant. How would HMAC-SHA-256 > be supported? The digest mechanism has been removed. > Section 5.2.7 says: > > When HMAC-SHA1 is used, the input text needs to be padded so as > > to be a multiple of 64 bytes. > Why? HMAC-SHA-1 can be used to authenticate messages of arbitrary > size. The digest mechanism has been removed. > > Section 7 makes TLS mandatory for servers but not for clients. > The authors need to consider the requirements of RFC 4107. I believe > this specification requires automated key management; if there is a > convincing argument why manual key management is appropriate, it needs > to be stated clearly, probably deserving a subsection in the security > considerations. I think the easiest fix is to require clients to > implement TLS so that there is mandatory automated key management. Now TLS is mandatory for all BFCP nodes (both servers and clients). > > In sections 6 and 7, how does a client know whether a particular > connection is using TLS? How about a server? Are separate ports > required? TLS now is mandatory. I have also added text saying that nodes should check that messages coming over a given TLS connection use a valid User ID to avoid attacks. > There is a conflict between section 9.1 and 9.2. Section 9.1 assumes > that both parties in the TLS exchange have certificates. However > section 9.2 assumes that the client is not authenticated and is using > the digest attribute for authentication. Please resolve this > conflict. I think the conflict also spills over into the text in > section 14. Presumably the desire is to support clients without > certificates; make it clear in section 9.1 that this is permitted and > make it clear in sections 9.2 and 14 that there are three modes to > consider: TLS with all parties having certificates, TLS with the > server having a certificate but the client not having a certificate, > and no TLS protection at all. Also, what happens if a client has a > certificate that the server is unwilling accept? Does it use the > digest attribute? If so, how does it know it should use the digest > attribute instead of depending on TLS level authentication? Now digest has been removed and TLS with self-signed certificates is the mechanism to use. > The assumption in section 9.2 seems to be that servers are > authenticated to clients via TLS, but this is only true if the client > can validate the certificate. In the absence of TLS protection, the > client's DIGEST-protected message can be replayed by a man-in-the- > middle to a real server. If the DIGEST attribute is only required > for the first message, then the man-in-the-middle can inject future > messages. The document needs to specify under what circumstances > clients verify certificates, and several details on certificate > verification need to be described. What subject names are expected > in the server's certificate? Must the client always have fingerprints > of certificates through mechanisms similar to [13]? If certificates > are ever accepted without verification, then the vulnerability to > man-in-the-middle with only the first message containing DIGEST > attributes needs to be discussed in the security considerations > section. Now TLS is mandatory and digest has been removed. > Section 9.2 needs to be strengthened. It needs to require that the > DIGEST attribute be the last attribute in the message. I want to > confirm that clients only use the NONCE once and that they must wait > for a server response to see if the NONCE attribute is included in > order to know whether to include a NONCE attribute in the next > message. Is 16-bits really larger enough for a nonce? Given the > requirement that "and a NONCE attribute with a nonce value that is > unguessable by attackers," 2**16 possible values seems too few. > Further, please reference RFC 4086 regarding nonce value generation. > Why does the nonce need to be unguessable anyway? It seems like > requiring nonces never be reused with a given shared secret is > sufficient. Digest has been removed. > > Section 9.2, I believe there are problems if an unauthenticated > server can tell a client what nonce value to use. The most serious > problem involves a server that supports TLS and a client that does > not require TLS. An attacker can trick the client into not using > TLS. The attacker sends a message to the server without a NONCE > attribute or DIGEST attribute, sees what nonce value the server > wants, and then generates an error reply to the real client > requesting this nonce value. The client responds with some message > including the NONCE and DIGEST attributes. The attacker then > sends this message to the server. Since the attacker is using TLS > to communicate to the server and since the server only requires > the first message to be authenticated, the attacker may now send any > message authenticated as the client. This attack must be thwarted, > possibly by defining an attribute indicating that a particular > message (is|is not) being sent over a TLS channel. Any remaining > attacks based on the fact that the error containing the nonce > value is not authenticated must be documented. Digest has been removed. > > Section 9.2 chooses not to authenticate messages from the server to > the client. I don't like this design decision and would recommend > that the working group change its mind. However I cannot require this > change. I do require that this decision be clearly documented. This > is especially problematic when the nonce value is sent to the client. > Without the DIGEST attribute on this message, the client has no way > to determine that the nonce value is actually coming from the server. Now TLS is mandatory and digest has been removed. > Section 9.2 assumes that the shared secret can be used with any digest > algorithm. I don't think it is guaranteed that all keys are valid > with all algorithms. For example, HMAC-SHA-1 has a minimum requirement > on the key size. Digest has been removed. > > The security considerations section seems to gloss over many attacks > and simply recommend using TLS. Please do separate security analysis > for the protocol when TLS is used and the protocol when just the > digest attribute is used. Once that is done, I'd like to re-review. Now TLS is mandatory. > > Scott Hollenbeck: > > Comment [2005-08-29]: > The document uses the word "byte" in many places to describe things like pad > values. While I'll agree that a byte contains 8 bits on most modern computers, > it's generally better to use "octet" if 8-bit values are being described. Done. > Russ Housley: > > Comment [2005-08-31]: > > Sam Hartman and I had a long discussion about this document, and > we decided that it would be best if only one DISCUSS ballot position > is posted by a Security Area Director. As a result, Sam is posting > a DISCUSS position, and I am posting a NO-OBJECTION position. The > position posted by Sam is a union of our concerns, and the authors > only need to work with one Security Area Director to resolve the > concerns that are being raised. As a result of my discussions with Sam, I have removed the digest mechanism from the document. > > Bert Wijnen: > > Comment [2005-09-01]: > > I think that this informative reference: > [13] Camarillo, G., "Session Description Protocol (SDP) Format for > Binary Floor Control Protocol (BFCP) Streams", > draft-ietf-mmusic-sdp-bfcp-01 (work in progress), May 2005. > > Should really be a normative reference. As far as I can tell, you better > understand the content of that mmusic-sdb-bfcp if you want to implement > this xcon-bfcp specification. > Changed to normative. Thanks, Gonzalo ------- End of Forwarded Message _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Sat Dec 10 04:47:14 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 1El1Jy-0005Pv-E0; Sat, 10 Dec 2005 04:47:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1El1Jw-0005LO-5L for xcon@megatron.ietf.org; Sat, 10 Dec 2005 04:47: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 EAA05515 for ; Sat, 10 Dec 2005 04:46:18 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1El1KH-0008Pz-TM for xcon@ietf.org; Sat, 10 Dec 2005 04:47:35 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 322C74E1 for ; Sat, 10 Dec 2005 10:47:02 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sat, 10 Dec 2005 10:47:02 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sat, 10 Dec 2005 10:47:01 +0100 Received: from [131.160.126.89] (rvi2-126-89.lmf.ericsson.se [131.160.126.89]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9DF6D2441 for ; Sat, 10 Dec 2005 11:47:01 +0200 (EET) Message-ID: <439AA415.4040606@ericsson.com> Date: Sat, 10 Dec 2005 11:47:01 +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: 10 Dec 2005 09:47:01.0845 (UTC) FILETIME=[ABADC850:01C5FD6E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [XCON] New draft: draft-ietf-xcon-bfcp-connection-00.txt 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, as agreed in the last XCON meeting, I have removed the digest mechanism from the main BFCP spec. I have also made some changes to the MMUSIC draft so that both specs are aligned (see Allison's email with a description of all the changes). I have moved the definition of the digest mechanism and the discussions on how to establish BFCP connections outside an offer/answer exchange to a new draft. Until it appears in the archives, you can fetch it from: http://users.piuha.net/gonzalo/temp/draft-ietf-xcon-bfcp-connection-00.txt Cheers, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Dec 12 13:56:08 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 1ElsqG-0006BG-O9; Mon, 12 Dec 2005 13:56:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElsqA-00064p-6u; Mon, 12 Dec 2005 13:56:06 -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 NAA01639; Mon, 12 Dec 2005 13:54:56 -0500 (EST) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Elsqo-0007Tz-VJ; Mon, 12 Dec 2005 13:56:45 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jBCItSul031200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Dec 2005 10:55:29 -0800 Received: from [67.188.157.106] (carbuncle.qualcomm.com [129.46.225.16]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id jBCItPFA013072; Mon, 12 Dec 2005 10:55:26 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <200512100338.jBA3ckj3018566@moria.qualcomm.com> References: <200512100338.jBA3ckj3018566@moria.qualcomm.com> Date: Mon, 12 Dec 2005 10:55:19 -0800 To: mankin@psg.com, hartmans-ietf@mit.edu, housley@vigilsec.com From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 Cc: mmusic@ietf.org, xcon@ietf.org, gonzalo.camarillo@ericsson.com, jon.peterson@neustar.biz Subject: [XCON] Re: Progressing/Resolving the IESG Review of the BFCP specs 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 I've cleared my DISCUSS. Thanks for the updates on USER-URI; the new text is much clearer, and I think it will help implementors get the right thing done here. regards, Ted At 7:38 PM -0800 12/9/05, Allison Mankin wrote: >Russ, Sam, Ted - > >Gonzalo has worked with you all, and spoke to the respective >working groups. He has published revisions of the two specs >which we believe should resolve your Discusses. Below are his >comments on how. I've added a bit of commentary inline at a few >places [AJM: ] > >Please let us know if you are able to clear now. > >Allison > >------ Gonzalo writes --- > > >I have put together new revisions of the BFCP drafts. They should >address all the discusses in the ID tracker. > >http://www.ietf.org/internet-drafts/draft-ietf-xcon-bfcp-06.txt >http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bfcp-03.txt > >Below I provide detailed answers to all the discusses: > >MMUSIC document: >https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1786&filename=draft-ietf-mmusic-sdp-bfcp > >> Bill Fenner: >> >> Discuss [2005-09-01]: Port 20000 belongs to a protocol named 'DNP'; >> should this example be from the dynamic port range (49152-65535) or >> should bfcp have an IANA-assigned port number? > >The draft now uses ports in the dynamic port range. > >[AJM: Bill has cleared his Discuss] > >> Sam Hartman: >> >> Discuss [2005-08-31]: 1) Please replace the RFc 1750 reference with >> RFC 4086. > >I have removed this reference as a result of removing the digest mechanism. > >> >> 2) RFC 3548 is an informational RFC but is referenced as a normative >> reference; RFC 3967 requires that this fact be mentioned in the last >> call. It was not. This document needs to be last called again or >> that reference changed. [Yes, I think this requirement is wrong; I >> also understand the argument that we should follow our rules >> consistently] > >I have removed this reference as a result of removing the digest mechanism. > > 3) I'm uncomfortable with this document being approved >> before draft-ietf-mmusic-media-tls. Based on how this protocol >> works, I suspect I have comments on that draft and depending on how >> those comments are resolved, I think this draft may change. In >> particular, I'm concerned about cases where the active open side of >> the connection is the TLS server, the handling of the fingerprint >> attribute and some concerns about asymmetry in this protocol. > >[AJM: Sam, draft-ietf-mmusic-media-tls is in IETF Last Call now - > I am shepherding it. There will be no change initiated by the > working group. We really need your comments on the draft - > I solicited this from you again in a pre-IETF Last Call heads > up. There's some time pressure because of outside bodies > calling these protocols critical dependencies...] > >This draft normatively depends on the SDP TLS draft. So, in any case, it >will need to wait for it before it can be published as an RFC. > >> >> 4) This document is not aligned with the main BFCP document. First, >> if the server can do active opens then section 6 and 14 of the BFCP >> document need to discuss that. If the authors of this document >> confirm that this document's behavior is correct, then I can amend my >> BFCP discuss. > >I have clarified in the main BFCP spec that the floor control server can >do active opens. > >> 5) The authentication handling in this document is not aligned with >> BFCP. Section 8.1 of this document implies that digest is not used >> if TLS is used; as discussed by section 9.2 of the BFCP document, >> BFCP seems to support modes where both TLS and digest are used. >> Similarly, section 8.2.1 only allows the digest shared secret to be >> negotiated for tcp/bfcp not tcp/tls/bfcp. Again, I'm happy if these >> document are aligned in either direction. > >I have removed the digest mechanism from the drafts. Now TLS is mandated. > >> 6) IT seems like the attributes discussed in section 8.1 need to be >> integrity protected. However the security considerations does not > > discuss this issue. > >I have removed the digest mechanism from the drafts. Now TLS is mandated. > >> Comment [2005-08-31]: I'm not sure I see a way that a server can >> offer both a TLS and non-TLS stream using this media type. If >> clients end up being required to support TLS tihs probably doesn't >> matter. However it may be an issue if clients are not required to >> support TLS. Perhaps I'm missing some information about how >> offer/answer works. It definitely seems that two m lines would be >> wrong because then a client could accept both of them. > >Now TLS is mandated. > >> >> Russ Housley: >> >> Discuss [2005-09-01]: >> >> The value "c2hhcmVkLXNlY3JldA==" is used throughout the document as >> the shared secret example value. While the ASCII string that was >> encoded to make this value is cute, the string is not long enough. >> RFC 2104 recommends that the key for HMAC-SHA-1 be 20 octets. > >I have removed the digest mechanism from the drafts. Now TLS is mandated. > >> I find the structure of section 8 very confusing. The authentication >> of the SIP session that is used to perform an offer/answer exchange >> is not clearly separated from the authentication of the BFCP protocol >> entities. Further, if the 'fingerprint' attribute is not present, >> what checks must be performed to ensure that the non-self-signed >> certificate used for offer/answer exchange authentication belongs to >> to the same party as the non-self-signed certificate used with >> BFCP/TLS/TCP. This (and perhaps other related topics) belong in a >> subsection that does not currently exist. > >With the removal of the digest mechanism everything should be clearer. > >> Section 8 says: >>> >>> Note that when mutual authentication is performed using TLS, it is >>> not necessary to use this digest mechanism. >>> >> This does not agree with draft-ietf-xcon-bfcp-05, which says that the >> digest mechanism must be used for the first message, even when TLS >> is employed. >> >> Section 8.1 says: >>> >>> ... the certificate provided at the TLS-level must be signed by a >>> certificate authority known to other party. >>> >> This is not quite correct, and the terminology does not align with >> RFC 3280. I suggest: >>> >>> ... the certificate provided at the TLS-level MUST either be >>> directly signed by one of the other party's trust anchors or be >>> validated using a certification path that terminates at one of the >>> other party's trust anchors. >>> > >I have modifies the text according to your suggestion. > >> Also, a normative reference to RFC 3280 in this section is desirable. >> > >Added. > >> >> Section 8.2.1 says: >>> >>> The key-params field SHOULD use the 'inline' key method followed by >>> a base64-encoded [6] unguessable secret [1]. >>> >> Please state the size of the shared secret value. I suspect that the >> size depends on the selected integrity check function. > >The digest mechanism has been removed from the draft. > >> >> Bert Wijnen: >> >> Comment [2005-09-01]: >> >> This document has a normative reference: [9] Levin, O. and G. >> Camarillo, "The SDP (Session Description Protocol) Label Attribute", >> draft-levin-mmmusic-sdp-media-label-00 (work in progress), July 2004. >> >> >> and that document is an individual Internet-Draft, that also has >> expired. So what impact does this have? > >I have updated the reference to draft-ietf-mmusic-sdp-media-label, which >is a WG item. > >[AJM: and it is in the RFC Editor Queue] > > >XCON document: >https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1785&filename=draft-ietf-xcon-bfcp > >> Brian Carpenter: >> >> Comment [2005-09-01]: >> Comment from John Loughney >> >> Intro says: >> >> The Requirements for Floor Control Protocol [10] list a set of >> requirements that need to be met by floor control protocols. The >> Binary Floor Control Protocol (BFCP), which is specified in this >> document, meets these requirements. >> >> -> "Requirements for Floor Control Protocol" seems to have expired. > > Awfully hard to know if the requirements have been met by this >> protocol, if they've expired ... > >The requirements document has already been approved and is in the RFC >Editor's queue at this point. > >> >> Ted Hardie: >> >> Discuss [2005-08-31]: >> The document says that it fulfills the requirements of >> draft-ietf-xcon-floor-control-req, but the draft >> has apparently expired. > >The requirements document has already been approved and is in the RFC >Editor's queue at this point. > >> >> The document describes the USER-URI field by saying: >> >> Text: this field contains the UTF-8 encoded URI of the user. >> >> Further details on what is meant by this seem required to get interoperable >> use. The document >> does note that it is returned in responses to User Query messages, but it is not >> clear if it is >> limited to a contact uri or has a broader applicability. > >I have clarified the scope of this attribute. > >> >> Sam Hartman: >> >> Discuss [2005-08-31]: >> Section 5.2 says: >> > Length: this 8-bit field contains the length of the attribute in >> > bytes, excluding any padding defined for specific attributes. >> If I understand this text correctly, it means that a new attribute >> can be defined with padding requirements such that the length byte >> is not enough to find the end of this attribute and the beginning >> of the next attribute because the padding is not included in the >> length. This seems against the goal of having extensible attributes. > >All the attributes are32-bit aligned. Therefore, it is always possible >to find the next attribute. > >> Section 5.2.7 indicates that the length of the DIGEST attribute >> payload is always 24 bytes. This seems to be composed of: >> header = 2 bytes >> algorithm = 1 byte >> digest = 20 bytes (for HMAC-SHA-1) >> padding = 2 bytes >> This adds up to 25 bytes. Please correct. Also, the size of >> this attribute should not be constant. How would HMAC-SHA-256 >> be supported? > >The digest mechanism has been removed. > >> Section 5.2.7 says: >> > When HMAC-SHA1 is used, the input text needs to be padded so as >> > to be a multiple of 64 bytes. >> Why? HMAC-SHA-1 can be used to authenticate messages of arbitrary >> size. > >The digest mechanism has been removed. > >> >> Section 7 makes TLS mandatory for servers but not for clients. >> The authors need to consider the requirements of RFC 4107. I believe >> this specification requires automated key management; if there is a >> convincing argument why manual key management is appropriate, it needs >> to be stated clearly, probably deserving a subsection in the security >> considerations. I think the easiest fix is to require clients to >> implement TLS so that there is mandatory automated key management. > >Now TLS is mandatory for all BFCP nodes (both servers and clients). > >> >> In sections 6 and 7, how does a client know whether a particular >> connection is using TLS? How about a server? Are separate ports >> required? > >TLS now is mandatory. I have also added text saying that nodes should >check that messages coming over a given TLS connection use a valid User >ID to avoid attacks. > >> There is a conflict between section 9.1 and 9.2. Section 9.1 assumes >> that both parties in the TLS exchange have certificates. However >> section 9.2 assumes that the client is not authenticated and is using >> the digest attribute for authentication. Please resolve this >> conflict. I think the conflict also spills over into the text in >> section 14. Presumably the desire is to support clients without >> certificates; make it clear in section 9.1 that this is permitted and >> make it clear in sections 9.2 and 14 that there are three modes to >> consider: TLS with all parties having certificates, TLS with the >> server having a certificate but the client not having a certificate, >> and no TLS protection at all. Also, what happens if a client has a >> certificate that the server is unwilling accept? Does it use the >> digest attribute? If so, how does it know it should use the digest >> attribute instead of depending on TLS level authentication? > >Now digest has been removed and TLS with self-signed certificates is the > mechanism to use. > >> The assumption in section 9.2 seems to be that servers are >> authenticated to clients via TLS, but this is only true if the client > > can validate the certificate. In the absence of TLS protection, the >> client's DIGEST-protected message can be replayed by a man-in-the- >> middle to a real server. If the DIGEST attribute is only required >> for the first message, then the man-in-the-middle can inject future >> messages. The document needs to specify under what circumstances >> clients verify certificates, and several details on certificate >> verification need to be described. What subject names are expected >> in the server's certificate? Must the client always have fingerprints >> of certificates through mechanisms similar to [13]? If certificates >> are ever accepted without verification, then the vulnerability to >> man-in-the-middle with only the first message containing DIGEST >> attributes needs to be discussed in the security considerations >> section. > >Now TLS is mandatory and digest has been removed. > >> Section 9.2 needs to be strengthened. It needs to require that the >> DIGEST attribute be the last attribute in the message. I want to >> confirm that clients only use the NONCE once and that they must wait >> for a server response to see if the NONCE attribute is included in >> order to know whether to include a NONCE attribute in the next >> message. Is 16-bits really larger enough for a nonce? Given the >> requirement that "and a NONCE attribute with a nonce value that is >> unguessable by attackers," 2**16 possible values seems too few. >> Further, please reference RFC 4086 regarding nonce value generation. >> Why does the nonce need to be unguessable anyway? It seems like >> requiring nonces never be reused with a given shared secret is >> sufficient. > >Digest has been removed. > >> >> Section 9.2, I believe there are problems if an unauthenticated >> server can tell a client what nonce value to use. The most serious >> problem involves a server that supports TLS and a client that does >> not require TLS. An attacker can trick the client into not using >> TLS. The attacker sends a message to the server without a NONCE >> attribute or DIGEST attribute, sees what nonce value the server >> wants, and then generates an error reply to the real client >> requesting this nonce value. The client responds with some message >> including the NONCE and DIGEST attributes. The attacker then >> sends this message to the server. Since the attacker is using TLS >> to communicate to the server and since the server only requires >> the first message to be authenticated, the attacker may now send any >> message authenticated as the client. This attack must be thwarted, >> possibly by defining an attribute indicating that a particular >> message (is|is not) being sent over a TLS channel. Any remaining >> attacks based on the fact that the error containing the nonce >> value is not authenticated must be documented. > >Digest has been removed. > >> >> Section 9.2 chooses not to authenticate messages from the server to >> the client. I don't like this design decision and would recommend >> that the working group change its mind. However I cannot require this >> change. I do require that this decision be clearly documented. This >> is especially problematic when the nonce value is sent to the client. >> Without the DIGEST attribute on this message, the client has no way >> to determine that the nonce value is actually coming from the server. > >Now TLS is mandatory and digest has been removed. > >> Section 9.2 assumes that the shared secret can be used with any digest >> algorithm. I don't think it is guaranteed that all keys are valid >> with all algorithms. For example, HMAC-SHA-1 has a minimum requirement >> on the key size. > >Digest has been removed. > >> >> The security considerations section seems to gloss over many attacks >> and simply recommend using TLS. Please do separate security analysis >> for the protocol when TLS is used and the protocol when just the >> digest attribute is used. Once that is done, I'd like to re-review. > >Now TLS is mandatory. > >> >> Scott Hollenbeck: > > >> Comment [2005-08-29]: >> The document uses the word "byte" in many places to describe things like pad >> values. While I'll agree that a byte contains 8 bits on most modern computers, > > it's generally better to use "octet" if 8-bit values are being described. > >Done. > >> Russ Housley: >> >> Comment [2005-08-31]: >> >> Sam Hartman and I had a long discussion about this document, and >> we decided that it would be best if only one DISCUSS ballot position >> is posted by a Security Area Director. As a result, Sam is posting >> a DISCUSS position, and I am posting a NO-OBJECTION position. The >> position posted by Sam is a union of our concerns, and the authors >> only need to work with one Security Area Director to resolve the >> concerns that are being raised. > >As a result of my discussions with Sam, I have removed the digest >mechanism from the document. > >> >> Bert Wijnen: >> >> Comment [2005-09-01]: >> >> I think that this informative reference: >> [13] Camarillo, G., "Session Description Protocol (SDP) Format for >> Binary Floor Control Protocol (BFCP) Streams", >> draft-ietf-mmusic-sdp-bfcp-01 (work in progress), May 2005. >> >> Should really be a normative reference. As far as I can tell, you better >> understand the content of that mmusic-sdb-bfcp if you want to implement >> this xcon-bfcp specification. >> > >Changed to normative. > > >Thanks, > >Gonzalo > > > >------- End of Forwarded Message _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Dec 12 15:49:48 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 1ElucG-00022K-RP; Mon, 12 Dec 2005 15:49:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ElucB-00021R-W8; Mon, 12 Dec 2005 15:49:46 -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 PAA24927; Mon, 12 Dec 2005 15:48:47 -0500 (EST) Message-Id: <200512122048.PAA24927@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Elud2-000626-SD; Mon, 12 Dec 2005 15:50:38 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eluc9-000Dc5-A1; Mon, 12 Dec 2005 20:49:41 +0000 To: mmusic@ietf.org Date: Mon, 12 Dec 2005 12:49:41 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: hardie@qualcomm.com, jon.peterson@neustar.biz, hartmans-ietf@mit.edu, housley@vigilsec.com, gonzalo.camarillo@ericsson.com, xcon@ietf.org Subject: [XCON] Re: Progressing/Resolving the IESG Review of the BFCP specs 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 to Russ and Ted for the prompt re-review of the BFCP documents. Russ wrote: > This document depends on the fingerprint Attribute definition in > [10], which is draft-ietf-mmusic-comedia-tls-05. The definition of > the fingerprint attribute includes: hash-func = "sha-1" / "sha-224" / "sha-256" / "sha-384" / "sha-512" / "md5" / "md2" / token ; Additional hash functions can only come ; from updates to RFC 3279 > RFC 3279 does not define the short strings used here. RFC 3279 > provides ASN.1 object identifiers, which are not suitable > here. draft-ietf-mmusic-comedia-tls needs to say how these > identifiers will be assigned. Will IANA maintain a registry? Good point. I'll note to the WG that Russ also sent this to the IESG as a Last Call comment on the document. There are some instances when attribute values are registered in IANA, not just the att-field. One that is comparable is the key management protocol identifier from draft-ietf-mmusic-kmgmt-ext. So a suggestion is to add to the IANA Considerations a crisp new sub-registry for the hash-func values in the fingerprint attribute. Its rules for registration can be that new identifiers are permitted only for hash functions found in RFC 3279 or updates of RFC 3279. Does the editor want to propose some IANA Considerations text? Allison (wearing the hat of an AD shepherd for comedia-tls) _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Dec 13 13:33:23 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 1EmExn-0002dC-Cf; Tue, 13 Dec 2005 13:33:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmExd-0002br-H5; Tue, 13 Dec 2005 13:33:21 -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 NAA03717; Tue, 13 Dec 2005 13:32:04 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmEyU-0003Ca-Ad; Tue, 13 Dec 2005 13:34:08 -0500 Received: from cnr.cs.columbia.edu (cnr.cs.columbia.edu [128.59.19.133]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jBDIWpQw001230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Dec 2005 13:32:51 -0500 (EST) Received: from cnr.cs.columbia.edu (localhost [127.0.0.1]) by cnr.cs.columbia.edu (8.13.3/8.13.3) with ESMTP id jBDIWoG2089570; Tue, 13 Dec 2005 13:32:50 -0500 (EST) (envelope-from lennox@cnr.cs.columbia.edu) Received: (from lennox@localhost) by cnr.cs.columbia.edu (8.13.3/8.13.3/Submit) id jBDIWkxr089567; Tue, 13 Dec 2005 13:32:46 -0500 (EST) (envelope-from lennox) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17311.5070.589311.939533@cnr.cs.columbia.edu> Date: Tue, 13 Dec 2005 13:32:46 -0500 To: Russ Housley In-Reply-To: <7.0.0.10.2.20051212142348.0369a800@vigilsec.com> References: <7.0.0.10.2.20051212142348.0369a800@vigilsec.com> X-Mailer: VM 7.19 under Emacs 21.3.1 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.8 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: hardie@qualcomm.com, mmusic@ietf.org, jon.peterson@neustar.biz, hartmans-ietf@mit.edu, xcon@ietf.org, gonzalo.camarillo@ericsson.com Subject: [XCON] Re: [MMUSIC] Re: Progressing/Resolving the IESG Review of the BFCP specs 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 Monday, December 12 2005, "Russ Housley" wrote to "mankin@psg.com, hartmans-ietf@mit.edu, hardie@qualcomm.com, mmusic@ietf.org, xcon@ietf.org, gonzalo.camarillo@ericsson.com, jon.peterson@neustar.biz, mankin@psg.com" saying: > This document depends on the fingerprint Attribute definition in > [10], which is draft-ietf-mmusic-comedia-tls-05. The definition of > the fingerprint attribute includes: > > hash-func = "sha-1" / "sha-224" / "sha-256" / > "sha-384" / "sha-512" / > "md5" / "md2" / token > ; Additional hash functions can only come > ; from updates to RFC 3279 > > RFC 3279 does not define the short strings used here. RFC 3279 > provides ASN.1 object identifiers, which are not suitable > here. draft-ietf-mmusic-comedia-tls needs to say how these > identifiers will be assigned. Will IANA maintain a registry? It could be an IANA registry; I can write an IANA considerations section. A registry of hash function names seems like something that's useful more broadly than just for the TLS Comedia fingerprint, though. For instance, at some point RFC 2617 is going to need new hash functions. Should this problem be solved in more generality? -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Dec 14 00:28:46 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 1EmPC2-0005AG-Sx; Wed, 14 Dec 2005 00:28:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmPC1-00059B-Ai for xcon@megatron.ietf.org; Wed, 14 Dec 2005 00:28:45 -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 AAA27761 for ; Wed, 14 Dec 2005 00:27:47 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmPD9-0005DL-6A for xcon@ietf.org; Wed, 14 Dec 2005 00:29:56 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 13 Dec 2005 21:28:35 -0800 X-IronPort-AV: i="3.99,250,1131350400"; d="scan'208"; a="240729017:sNHT31426552" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jBE5SWMe015249; Tue, 13 Dec 2005 21:28:33 -0800 (PST) Received: from 10.21.96.130 ([10.21.96.130]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Wed, 14 Dec 2005 05:28:32 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Tue, 13 Dec 2005 21:28:40 -0800 Subject: Re: [XCON] Conference Control: Path Forward From: Cullen Jennings To: Adam Roach , XCON-IETF Message-ID: Thread-Topic: [XCON] Conference Control: Path Forward Thread-Index: AcYAbz2Ce/P5lmxiEdq0TwARJEEJ/A== In-Reply-To: <43823C2B.5030807@nostrum.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit 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 Do you think CSCP has enough detail to be discussed as it? I certainly don't think it is done but I think it is far enough along for people to understand what it is. My comment on other proposals has been that it is not clear how they handle the variable part data. Our framework is clear we need that. At the last meeting, it seemed like the path Orit was thinking of taking CCCP was moving to the point where it was semantically the same as CSCP. I look forward to seeing how CCCP deal with this part of the problem. I also hope the next rev address simultaneous changes to the variable part while doing one of the operations corresponding to the the more static part. Having seen the current traffic on the list on this topic, I think our goal should be to have all this information in place for the next IETF meeting and try and finalize the decision then. On 11/21/05 1:29 PM, "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 Wed Dec 14 02:46: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 1EmRLV-0000v9-Mz; Wed, 14 Dec 2005 02:46:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmRLU-0000tF-Lj for xcon@megatron.ietf.org; Wed, 14 Dec 2005 02:46: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 CAA12254 for ; Wed, 14 Dec 2005 02:45:43 -0500 (EST) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmRMY-0001mv-J0 for xcon@ietf.org; Wed, 14 Dec 2005 02:47:52 -0500 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 04C294F004F; Wed, 14 Dec 2005 08:46:33 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Dec 2005 08:46:29 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Dec 2005 08:46:21 +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, 14 Dec 2005 08:46:20 +0100 Message-ID: Thread-Topic: New version of CSCP draft Thread-Index: AcYAbz2Ce/P5lmxiEdq0TwARJEEJ/AAEskTw From: "Oscar Novo \(JO/LMF\)" To: "Cullen Jennings" , "Adam Roach" , "XCON-IETF" , "Gonzalo Camarillo \(JO/LMF\)" , X-OriginalArrivalTime: 14 Dec 2005 07:46:21.0685 (UTC) FILETIME=[79DC0A50:01C60082] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: Subject: [XCON] New version of CSCP draft 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 Hello, We would like to notify the new version of the CSCP draft. Until it appears in the archives, you can fetch it from: http://users.piuha.net/gonzalo/temp/draft-jennings-xcon-cscp-02.txt CSCP is an extension of the BFCP. In this version we have aligned the CSCP draft with the "Binary Floor Control Protocol (BFCP)" draft and the "Connection Establishment in the Binary Floor Control Protocol (BFCP)" draft. Here's an overall summary of the changes: - We have aligned the CSCP draft with the "Binary Floor Control Protocol (BFCP)" draft and the "Connection Establishment in the Binary Floor Control Protocol (BFCP)" draft=20 - Definition and explanation of the main errors of the CSCP protocol. - Added a new section 6 (Server Behaviour) - In Section 7 (example) added a new example and additional text explaining the example - Updated sections 9 (IANA Considerations) and section 10 (Security Considerations) CSCP is not done yet. There are changes that have to be incorporated in the following versions: - Definition of new operations (creation of a conference, termination of a conference, etc...) - Definition of new error values of the protocol - Better explanation of some operations (Adding Elements, etc...) - Discussion about the need of the synchronous "query" mechanism in the protocol But we believe it's enough to understand the propose of this protocol and to discuss in the mailing list if this protocol is a good option. The strengths of CSCP are: - CSCP is based on BFCP, reducing the number of protocols required to be supported by clients - It can modify the "variable" part data and the "common" part data using the same operations. - Easy to implement - Compact and Efficient Regards, Oscar _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Dec 16 15:45:06 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 1EnMRu-0002Rf-L2; Fri, 16 Dec 2005 15:45:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnMRs-0002RX-UY; Fri, 16 Dec 2005 15:45:05 -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 PAA12191; Fri, 16 Dec 2005 15:44:04 -0500 (EST) Message-Id: <200512162044.PAA12191@ietf.org> Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnMTY-0006Lg-20; Fri, 16 Dec 2005 15:46:49 -0500 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EnMRa-000MNT-Q5; Fri, 16 Dec 2005 20:44:46 +0000 To: Sam Hartman Date: Fri, 16 Dec 2005 12:44:46 -0800 From: Allison Mankin X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: hardie@qualcomm.com, mmusic@ietf.org, jon.peterson@neustar.biz, housley@vigilsec.com, xcon@ietf.org, gonzalo.camarillo@ericsson.com Subject: [XCON] Re: Progressing/Resolving the IESG Review of the BFCP specs X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mankin@psg.com List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org Thanks to Sam for his responsive re-review. So, XCON and MMUSIC Working Groups: draft-ietf-xcon-bfcp-06.txt is approved now draft-ietf-mmusic-sdp-bfcp-03.txt is approved now Congratulations! The normative dependencies, the TLS comedia and sdp-new, are now well into the pipeline. We are just finishing IANA's questions on sdp-new before approval; TLS comedia is in IETF Last Call and should go before the IESG at the beginning of January. So, news on that next year :) Allison _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Dec 16 15:50: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 1EnMWu-00038g-A1; Fri, 16 Dec 2005 15:50:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnMWh-00030b-Fi; Fri, 16 Dec 2005 15:50:03 -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 PAA12490; Fri, 16 Dec 2005 15:49:02 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnMYM-0006VC-ID; Fri, 16 Dec 2005 15:51:47 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EnMWf-0006Ci-Ms; Fri, 16 Dec 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 16 Dec 2005 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-bfcp-connection-00.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Connection Establishment in the Binary Floor Control Protocol (BFCP) Author(s) : G. Camarillo Filename : draft-ietf-xcon-bfcp-connection-00.txt Pages : 14 Date : 2005-12-16 This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. This document also specifies a digest authentication mechanism for BFCP based on shared secrets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-bfcp-connection-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-xcon-bfcp-connection-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-xcon-bfcp-connection-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-12-16113045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-bfcp-connection-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-bfcp-connection-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-12-16113045.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --NextPart-- From xcon-bounces@ietf.org Fri Dec 16 16:24:05 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 1EnN3d-0003xu-QS; Fri, 16 Dec 2005 16:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnMBf-0007Gg-09; Fri, 16 Dec 2005 15:28:19 -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 PAA10446; Fri, 16 Dec 2005 15:27:18 -0500 (EST) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnMDJ-0005pN-Ax; Fri, 16 Dec 2005 15:30:02 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 856A6E0070; Fri, 16 Dec 2005 15:28:09 -0500 (EST) To: mankin@psg.com References: <200512100338.jBA3cht8022206@fort-point-station.mit.edu> From: Sam Hartman Date: Fri, 16 Dec 2005 15:28:09 -0500 In-Reply-To: <200512100338.jBA3cht8022206@fort-point-station.mit.edu> (Allison Mankin's message of "Fri, 09 Dec 2005 19:38:41 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 X-Mailman-Approved-At: Fri, 16 Dec 2005 16:23:58 -0500 Cc: hardie@qualcomm.com, mmusic@ietf.org, jon.peterson@neustar.biz, housley@vigilsec.com, gonzalo.camarillo@ericsson.com, xcon@ietf.org Subject: [XCON] Re: Progressing/Resolving the IESG Review of the BFCP specs 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 I'm clearing all my discusses on the BFCP documents. Thanks for the great work. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Dec 20 11:53:36 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 1Eokk4-0006PD-QY; Tue, 20 Dec 2005 11:53:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eokk3-0006Nt-Eq for xcon@megatron.ietf.org; Tue, 20 Dec 2005 11:53:35 -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 LAA28984 for ; Tue, 20 Dec 2005 11:52:32 -0500 (EST) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EokmV-0004am-R9 for xcon@ietf.org; Tue, 20 Dec 2005 11:56:08 -0500 Received: from dsl027-191-178.sfo1.dsl.speakeasy.net ([216.27.191.178] helo=[10.75.74.128]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1Eokjq-0002Gj-JT; Tue, 20 Dec 2005 11:53:22 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 216.27.191.178 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <43A836F5.9030707@tello.com> Date: Tue, 20 Dec 2005 08:53:09 -0800 From: Alan Johnston User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Oscar Novo (JO/LMF)" Subject: Re: [XCON] New version of CSCP draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , Adam Roach , XCON-IETF , "Gonzalo Camarillo \(JO/LMF\)" 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 (not as chair) There are two areas that I would find useful to be discussed, either in the draft or on the list that may help me and others in evaluating this proposal. First, while I undestand how the protocol can be used to change a single value (mute a line, change a display name, etc.) to me it is not at all clear how a conference could be created, or a new user added as a dial out participant. Could you show the sequence of messages needed to obtain this. Secondly, this approach seems to essentially be a data manipulation approach. As such, the question of why XCAP is not used is important, as XCAP is nearly finished and will likely be already implemented as a protocol on many of the conference participant devices. Also, are the document locking capabilities of XCAP needed? If not, some advice for implementors on how to resolve conflicts in large conferences. Thanks, Alan Johnston sip:ajohnston@tello.com Oscar Novo (JO/LMF) wrote: >Hello, > >We would like to notify the new version of the CSCP draft. Until it >appears in the archives, you can fetch it from: > >http://users.piuha.net/gonzalo/temp/draft-jennings-xcon-cscp-02.txt > >CSCP is an extension of the BFCP. In this version we have aligned the >CSCP draft with the "Binary Floor Control Protocol (BFCP)" draft and the >"Connection Establishment in the Binary Floor Control Protocol (BFCP)" >draft. > >Here's an overall summary of the changes: > >- We have aligned the CSCP draft with the "Binary Floor Control Protocol >(BFCP)" draft and the "Connection Establishment in the Binary Floor >Control Protocol (BFCP)" draft >- Definition and explanation of the main errors of the CSCP protocol. >- Added a new section 6 (Server Behaviour) >- In Section 7 (example) added a new example and additional text >explaining the example >- Updated sections 9 (IANA Considerations) and section 10 (Security >Considerations) > >CSCP is not done yet. There are changes that have to be incorporated in >the following versions: > >- Definition of new operations (creation of a conference, termination of >a conference, etc...) >- Definition of new error values of the protocol >- Better explanation of some operations (Adding Elements, etc...) >- Discussion about the need of the synchronous "query" mechanism in the >protocol > >But we believe it's enough to understand the propose of this protocol >and to discuss in the mailing list if this protocol is a good option. > >The strengths of CSCP are: > >- CSCP is based on BFCP, reducing the number of protocols required to be >supported by clients >- It can modify the "variable" part data and the "common" part data >using the same operations. >- Easy to implement >- Compact and Efficient > >Regards, > >Oscar > > >_______________________________________________ >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 Dec 20 12:05:59 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 1Eokw3-0003MN-7f; Tue, 20 Dec 2005 12:05:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eokw1-0003M0-Gx for xcon@megatron.ietf.org; Tue, 20 Dec 2005 12:05: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 MAA01069 for ; Tue, 20 Dec 2005 12:04:54 -0500 (EST) From: Umesh.Chandra@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EokyS-0005Do-KZ for xcon@ietf.org; Tue, 20 Dec 2005 12:08:30 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBKH4qvB019583; Tue, 20 Dec 2005 19:04:54 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Dec 2005 19:05:44 +0200 Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Dec 2005 11:05:37 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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] New version of CSCP draft Date: Tue, 20 Dec 2005 11:05:37 -0600 Message-ID: <815E2AF6A087FF45A68EF2F310ADE111D81432@daebe102.NOE.Nokia.com> In-Reply-To: <43A836F5.9030707@tello.com> Thread-Topic: [XCON] New version of CSCP draft Thread-Index: AcYFhkBejmj7uL9cR0KMQwQ3uEpQaQAACsqQ To: , X-OriginalArrivalTime: 20 Dec 2005 17:05:37.0948 (UTC) FILETIME=[996DEDC0:01C60587] X-Spam-Score: 0.3 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Cc: fluffy@cisco.com, adam@nostrum.com, xcon@ietf.org, gonzalo.camarillo@ericsson.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 Hi, I agree with Alan on his comments relating to CSCP. I had sent similar comments earlier in (March) to the mailing list. It would be helpful to have some example messages (like to which entity - the floor control server or the focus etc) the requests are directed to and how they change the XML. Locking mechanism if required needs to be discussed in the draft. BR Umesh=20 >-----Original Message----- >From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On=20 >Behalf Of ext Alan Johnston >Sent: Tuesday, December 20, 2005 10:53 AM >To: Oscar Novo (JO/LMF) >Cc: Cullen Jennings; Adam Roach; XCON-IETF; Gonzalo Camarillo (JO/LMF) >Subject: Re: [XCON] New version of CSCP draft > >(not as chair) > >There are two areas that I would find useful to be discussed,=20 >either in the draft or on the list that may help me and others=20 >in evaluating this proposal. > >First, while I undestand how the protocol can be used to=20 >change a single value (mute a line, change a display name,=20 >etc.) to me it is not at all clear how a conference could be=20 >created, or a new user added as a dial out participant. Could=20 >you show the sequence of messages needed to obtain this. > >Secondly, this approach seems to essentially be a data=20 >manipulation approach. As such, the question of why XCAP is=20 >not used is important, as XCAP is nearly finished and will=20 >likely be already implemented as a protocol on many of the=20 >conference participant devices. Also, are the document=20 >locking capabilities of XCAP needed? If not, some advice for=20 >implementors on how to resolve conflicts in large conferences. > >Thanks, >Alan Johnston >sip:ajohnston@tello.com > >Oscar Novo (JO/LMF) wrote: > >>Hello, >> >>We would like to notify the new version of the CSCP draft. Until it=20 >>appears in the archives, you can fetch it from: >> >>http://users.piuha.net/gonzalo/temp/draft-jennings-xcon-cscp-02.txt >> >>CSCP is an extension of the BFCP. In this version we have aligned the=20 >>CSCP draft with the "Binary Floor Control Protocol (BFCP)" draft and=20 >>the "Connection Establishment in the Binary Floor Control=20 >Protocol (BFCP)" >>draft. >> >>Here's an overall summary of the changes: >> >>- We have aligned the CSCP draft with the "Binary Floor Control=20 >>Protocol (BFCP)" draft and the "Connection Establishment in=20 >the Binary=20 >>Floor Control Protocol (BFCP)" draft >>- Definition and explanation of the main errors of the CSCP protocol. >>- Added a new section 6 (Server Behaviour) >>- In Section 7 (example) added a new example and additional text=20 >>explaining the example >>- Updated sections 9 (IANA Considerations) and section 10 (Security >>Considerations) >> >>CSCP is not done yet. There are changes that have to be=20 >incorporated in=20 >>the following versions: >> >>- Definition of new operations (creation of a conference, termination=20 >>of a conference, etc...) >>- Definition of new error values of the protocol >>- Better explanation of some operations (Adding Elements, etc...) >>- Discussion about the need of the synchronous "query"=20 >mechanism in the=20 >>protocol >> >>But we believe it's enough to understand the propose of this protocol=20 >>and to discuss in the mailing list if this protocol is a good option. >> >>The strengths of CSCP are: >> >>- CSCP is based on BFCP, reducing the number of protocols required to=20 >>be supported by clients >>- It can modify the "variable" part data and the "common" part data=20 >>using the same operations. >>- Easy to implement >>- Compact and Efficient >> >>Regards, >> >>Oscar >> >> >>_______________________________________________ >>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 Tue Dec 20 18:24: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 1Eoqqn-0000vr-G8; Tue, 20 Dec 2005 18:24:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eoqqh-0000ub-GC; Tue, 20 Dec 2005 18:24: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 SAA15566; Tue, 20 Dec 2005 18:23:48 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoqtC-0002oz-Cf; Tue, 20 Dec 2005 18:27:27 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1Eoqqf-0003wS-7p; Tue, 20 Dec 2005 18:24:49 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 20 Dec 2005 18:24:49 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: xcon chair , Internet Architecture Board , xcon chair , xcon mailing list , RFC Editor Subject: [XCON] Protocol Action: 'The Binary Floor Control Protocol (BFCP)' to Proposed Standard 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 The IESG has approved the following document: - 'The Binary Floor Control Protocol (BFCP) ' as a Proposed Standard This document is the product of the Centralized Conferencing Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-bfcp-06.txt Technical Summary Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. Working Group Summary The working group carefully reviewed architectures for this space, and several protocol directions, and then concluded that this was the right direction. There was strong support for this document, and it received multiple reviews during working group last call. Protocol Quality The Area Director has been told of test implementation (and implementation of test suites) for BFCP, within the context of its 3GPP usage. The Responsible Area Director was Allison Mankin. The Editor, Gonzalo Camarillo, took the initiative in shepherding the Discuss comments. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Dec 23 04:42: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 1EpjRi-0000eJ-Ev; Fri, 23 Dec 2005 04:42:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpjRg-0000eE-NE for xcon@megatron.ietf.org; Fri, 23 Dec 2005 04:42: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 EAA19003 for ; Fri, 23 Dec 2005 04:41:35 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpjUb-0002lV-QI for xcon@ietf.org; Fri, 23 Dec 2005 04:45:47 -0500 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 5E6064F0001; Fri, 23 Dec 2005 10:42:22 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Dec 2005 10:42:22 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 23 Dec 2005 10:42:22 +0100 Received: from [131.160.126.27] (rvi2-126-27.lmf.ericsson.se [131.160.126.27]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 92D1E236E; Fri, 23 Dec 2005 11:42:20 +0200 (EET) Message-ID: <43ABC67A.40600@ericsson.com> Date: Fri, 23 Dec 2005 11:42:18 +0200 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Johnston Subject: Re: [XCON] New version of CSCP draft References: <43A836F5.9030707@tello.com> In-Reply-To: <43A836F5.9030707@tello.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Dec 2005 09:42:22.0197 (UTC) FILETIME=[2C5DA250:01C607A5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , 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 Alan, > Secondly, this approach seems to essentially be a data manipulation > approach. As such, the question of why XCAP is not used is important, > as XCAP is nearly finished and will likely be already implemented as a > protocol on many of the conference participant devices. Could you summarize the reasons why the XCAP-based approach was abandoned in the first place? Thanks, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Dec 23 06:10:14 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 1EpkoQ-0000D3-DJ; Fri, 23 Dec 2005 06:10:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpkoP-0000Cy-6u for xcon@megatron.ietf.org; Fri, 23 Dec 2005 06:10:13 -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 GAA27568 for ; Fri, 23 Dec 2005 06:09:07 -0500 (EST) Received: from cluster-b.mailcontrol.com ([217.68.146.190] helo=rly26b.srv.mailcontrol.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpkrP-0005R8-I9 for xcon@ietf.org; Fri, 23 Dec 2005 06:13:20 -0500 Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly26b.srv.mailcontrol.com (MailControl) with ESMTP id jBNB9sFN001267; Fri, 23 Dec 2005 11:09:55 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 23 Dec 2005 11:09:53 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE031188DF@gbnewp0758m.eu.ubiquity.net> Thread-Topic: SIP Control Framework and IVR Package Thread-Index: AcYHsOYLTUoRxpfrQ1yzOs3ulFtrrwAABKGA From: "Chris Boulton" To: X-Scanned-By: MailControl A-05-40-01 (www.mailcontrol.com) on 10.66.0.136 X-Spam-Score: 0.3 (/) X-Scan-Signature: c3d1fcc6feccbcc611b6c309986f05f7 Cc: Asher Shiratzky , Tim Melanchuk , "McGlashan, Scott" Subject: [XCON] FW: SIP Control Framework and IVR Package 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="===============1506977250==" Sender: xcon-bounces@ietf.org Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1506977250== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C607B1.66AC254F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C607B1.66AC254F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For anyone who is interested see mail that follows. =20 Chris. =20 p.s. For those who want to subscribe to the media control mailing list - instructions below:- =20 Instructions:- =20 - generate a mail to majordomo@lists.ubiquitysoftware.com - place text 'subscribe mediactrl' in the body of the message (plain text) - Follow remaining on-screen instructions to confirm list subscription =20 All subsequent mails need to be sent to mediactrl@lists.ubiquitysoftware.com =20 =20 I have also set up an archive, which can be found at:- =20 http://www.ubiquitysoftware.com/archives/ =20 =20 -----Original Message----- From: Chris Boulton=20 Sent: 23 December 2005 11:06 To: mediactrl@lists.ubiquitysoftware.com Cc: 'McGlashan, Scott'; Tim Melanchuk; Asher Shiratzky; Eric Burger; 'drage@lucent.com'; 'Dolly, Martin C, ALABS' Subject: SIP Control Framework and IVR Package =20 Hi All, =20 A small group has just submitted two new drafts and would like expert opinion/review from the 'Mediactrl' mailing list. The following provides a brief introduction to the technology contained within the two specifications:- =20 - A Control Framework for the Session Initiation Protocol (SIP) =20 Abstract This document describes a Framework and protocol for application deployment where the application logic and processing are distributed. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between Application Servers and tightly associated external Servers e.g.Media Server. =20 The motivation for the creation of this Framework is to provide an interface suitable to meet the requirements of a distributed, centralized conference system, as defined by the XCON work group of the IETF. It is not, however, limited to this scope and it is envisioned that this generic Framework will be used for a wide variety of de-coupled control architectures between network entities. =20 =20 - An Interactive Voice (IVR) Control Package for the Session Initiation Protocol (SIP) =20 Abstract This document defines a Session Initiation (SIP) Control Package for Interactive Voice Response (IVR) interaction. The control of Media Servers and their related resources in decomposed network architectures plays an important role in various Next Generation Networks. This Control Package aims to fulfill IVR requirements using the SIP Control Framework [7]. =20 Until the drafts appear in the archives, they will be available from the following links:- =20 http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework -00.txt http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework -00.html =20 and =20 http://www.ubiquitysoftware.com/ietf/draft-boulton-ivr-control-package-0 0.txt http://www.ubiquitysoftware.com/ietf/draft-boulton-ivr-control-package-0 0.html =20 =20 More packages to follow in the New Year to expand and provide proof points for the Control Framework as well as strengthening the Media Server Control proposal (e.g. package for Conference support). =20 Mr Burger, the authors would be grateful if you could include these drafts on the Media Control web pages and remove Media Server Request Protocol.=20 =20 =20 Seasons Greetings to all, =20 The Authors. =20 Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribu= tion is strictly prohibited. If you are not the addressee, please notify t= he sender immediately and destroy all copies of this email. Unless otherwi= se expressly agreed in writing signed by an officer of Ubiquity Software Co= rporation, nothing in this communication shall be deemed to be legally bind= ing. Thank you. ------_=_NextPart_001_01C607B1.66AC254F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For anyone who is interested see mail = that follows.

 

Chris.

 

p.s. For those who want to subscribe to the media control mailing list – instructions below:-

 

Instructions:-

 

-   &nb= sp;      generate a mail to majordomo@lists.ubiqui= tysoftware.com

-   &nb= sp;      place text 'subscribe mediactrl' in the body of the mess= age (plain text)

-   &nb= sp;      Follow remaining on-screen instructions to confirm list subscription

 

All subsequent ma= ils need to be sent to media= ctrl@lists.ubiquitysoftware.com

 

 

I have also set up an archive, which can be found at:-

 

http://www.ubiquitysoftware.com/archives/

 

 

-----Original Message-----
From: Chris Boulton
Sent: 23= December 2005 11:06
To: mediactrl@lists.ubiquitysoftware.com
Cc: 'McGlashan, Scott'; Tim Melanchuk; Asher Shiratzky; Eric Burger; 'drage@lucent.com'; 'Dolly, Martin= C, ALABS'
Subject: SIP Control Framewo= rk and IVR Package

 

Hi All,

 

A small group has just submitted two new drafts a= nd would like expert opinion/review from the ‘Mediactrl’ mailing list.  The following provides a brief introduction to the technology contained within the two specifications:-

 

- A Control Framework for the Session Initiation Protocol (SIP)

 

Abstract

This document describes a Framework and protocol = for application deployment where the application logic and processing are distributed.  The framework uses the Session Initiation Protocol (SIP)= to establish an application-level control mechanism between Application Servers and tightly associated external Servers e.g.Media Server.

 

The motivation for the creation of this Framework= is to provide an interface suitable to meet the requirements of a distributed, centralized conference system, as defined by the XCON work group of the IETF.  It is not, however, limited to this scope and it is envisioned = that this generic Framework will be used for a wide variety of de-coupled control architectures between network entities.

 

 

- An Interact= ive Voice (IVR) Control Package for the Session Initiation Protocol (SIP)

 

Abstract

This document defines a Session Initiation (SIP) Control Package for Interactive Voice Response (IVR) interaction.  The control of Media Servers and their related resources in decomposed network architectures plays an important role in various Next Generation Networks.  This Control Package aims to fulfill IVR requirements using= the SIP Control Framework [7].

 

Until the drafts appear in the archives, they wil= l be available from the following links:-

 

http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-contro= l-framework-00.txt

http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-contr= ol-framework-00.html

 

and

 

http://www.ubiquitysoftware.com/ietf/draft-boulton-ivr-control-= package-00.txt

http://www.ubiquitysoftware.com/ietf/draft-boulton-ivr-control= -package-00.html

 

 

More packages to follow in the New Year to expand= and provide proof points for the Control Framework as well as strengthening the Media Server Control proposal (e.g. package for Conference support).=

 

Mr Burger, the authors would be grateful if you c= ould include these drafts on the Media Control web pages and remove Media Server Request Protocol.

 

 

Seasons Greetings to all,

 

The Authors.

 



Information contained in t= his e-mail and any attachments are intended for the use of the addressee on= ly, and may contain confidential information of Ubiquity Software Corporati= on. All unauthorized use, disclosure or distribution is strictly prohibited= .  If you are not the addressee, please notify the sender immediately = and destroy all copies of this email.  Unless otherwise expressly agre= ed in writing signed by an officer of Ubiquity Software Corporation, nothin= g in this communication shall be deemed to be legally binding. Thank-you ------_=_NextPart_001_01C607B1.66AC254F-- --===============1506977250== 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 --===============1506977250==-- From xcon-bounces@ietf.org Fri Dec 23 19:11: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 1Epx0X-0004jE-Nr; Fri, 23 Dec 2005 19:11:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epx0V-0004j3-Kn for xcon@megatron.ietf.org; Fri, 23 Dec 2005 19:11: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 TAA01202 for ; Fri, 23 Dec 2005 19:10:22 -0500 (EST) Received: from zrtps0kn.nortel.com ([47.140.192.55] helo=zrtps0kn.nortelnetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Epx3b-0008Hw-7p for xcon@ietf.org; Fri, 23 Dec 2005 19:14:43 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jBO0B9K01429 for ; Fri, 23 Dec 2005 19:11:09 -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 Date: Fri, 23 Dec 2005 18:11:08 -0600 Message-ID: Thread-Topic: DP4/4.1: Common Conference Information and Templates (in/out problem) Thread-Index: AcYIHopYabId4U2MS8u1t2Xg+6L2mw== From: "Mary Barnes" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Subject: [XCON] DP4/4.1: Common Conference Information and Templates (in/out problem) 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 all, There's been a group of us (XCON FW authors, current template authors and data model authors) discussing this point and a couple of related issues around the Common conference information, templates and blueprints offline since the IETF meeting. We've come to tenuous agreement amongst ourselves on a couple of aspects of this topic and wanted to continue and complete the discussion with the WG. I'm summarizing the issues and the changes proposed at this point to the framework to accomodate current thinking. I've labeled the related questions/topics we've discussed for convenience as DP4.2 and DP4.3 and I'll post those in separate threads to facilitate tracking the issues. Feedback would be appreciated - ideally supported by alternative and/or additional text .=20 Per discussion at the IETF-64, there still seemed to be some debate (beyond the basic data model approach discussed in the "Call for Consensus:Data model" thread initiated by Adam) on some fundamentals of the model defined in the framework. Basically, this is the DP4 issue as to whether the template is in the same object as the common conference information (i.e. "in") or whether it is a separate object (i.e. "out"). The framework has been based on the "in" concept barring any other conclusion by the WG, noting that the current definition of blueprint is quite explicit about this: "A conference blueprint is a static conference object within a conferencing system, which describes a typical conference setting supported by the system. A conference blueprint is the basis for creation of dynamic conference objects. A system may maintain multiple blueprints, each comprised of the common conference information, along with any number of templates." The discussion amongst the group seemed to lead to it's not being an in/out issue as much as it is either by-value or by-reference. It was suggested that we just chooose by-value for now, but that wasn't deemed practical in terms of the model put forth in the framework in terms of lots of flexibility, with optionality of templates. We did (tenuously) agree to support both. The Blueprint concept really requires that we support by-reference, and that's consistent with the current approach whereby the client fetches any templates from the server that it doesn't understand. At the same time, a barebones system could initially just support a few templates and by-value might make sense. But, again, I think it's too limiting for the vision represented in the framework to be the only option supported. =20 At this time, we're proposing something like the following be added after the 1st paragraph in 7.3 (where 7.3 is the "Advanced Example" section that introduces the blueprint concept) supporting the concept of by-value or by-reference. It might be useful to add more text including some background for the context for using one or the other, as well: "As defined within this framework, a blueprint is comprised of the common conference information and one or more templates. The templates within the blueprint can either be included by-value or by-reference depending upon the system implementation."=20 Mary. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Dec 23 19:12: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 1Epx1n-0005Mb-69; Fri, 23 Dec 2005 19:12:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epx1m-0005LY-1t for xcon@megatron.ietf.org; Fri, 23 Dec 2005 19:12: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 TAA01385 for ; Fri, 23 Dec 2005 19:11:43 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Epx4t-0008Le-Sz for xcon@ietf.org; Fri, 23 Dec 2005 19:16:04 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jBO0Ccj10474 for ; Fri, 23 Dec 2005 19:12:38 -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 Date: Fri, 23 Dec 2005 18:12:23 -0600 Message-ID: Thread-Topic: DP4.2: Defining new templates Thread-Index: AcYIHrZ2puiNOKyuSUWfCpCZ+pq0aQ== From: "Mary Barnes" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Subject: [XCON] DP4.2: Defining new templates 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 One of the points we discussed was: DP4.2 Whether clients can dynamically use new templates or whether new templates require new SW in clients? The current wording in the framework supports the former proposal,=20 specifically, section 7.3 currently states: "A client may need to query any templates in the blueprints that it doesn't understand and then make a decision on compatibility." Part of the confusion here (at least for me) is over what is meant by "new". There seemed to be unanimous agreement that a client can query a template that it doesn't currently have or has not previously used. That isn't the same thing as saying that templates can be dynamically created by a conferencing system. Per the framework, all the templates used by a conferencing system must be documented and registered. So, the discussion ended up being more around what could be changed within a template without requiring SW changes. After discussion, the group of authors seemed to agree that while modifications in the form of new controls added to elements of a template could be done without the need to register anything or define a new template, but adding new elements does require appropriate documentation and registration (i.e. a client can't be expected to understand new elements).=20 To clarify this, we could reasonably add something like the following the 2nd paragraph in section 5.2, which introduces the template concept: "It should be possible to modify the controls within an element of an existing template, without defining a new template. The client can than attempt to render the modified element to make use of the potential new functionality. However, adding new elements does require defining an entirely new template as discussed in the previous paragraph." Mary _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Dec 23 19:12: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 1Epx1t-0005No-LF; Fri, 23 Dec 2005 19:12:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epx1s-0005Nj-De for xcon@megatron.ietf.org; Fri, 23 Dec 2005 19:12:56 -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 TAA01397 for ; Fri, 23 Dec 2005 19:11:49 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Epx50-0008Lk-Af for xcon@ietf.org; Fri, 23 Dec 2005 19:16:10 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jBO0Cjj10486 for ; Fri, 23 Dec 2005 19:12:45 -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 Date: Fri, 23 Dec 2005 18:12:43 -0600 Message-ID: Thread-Topic: DP4.3: Can a blueprint contain more than one template Thread-Index: AcYIHsLY/d0M6P8ASWiJ3o4knd2DXw== From: "Mary Barnes" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Subject: [XCON] DP4.3: Can a blueprint contain more than one template 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 DP4.3 Is there more than one template associated with a given=20 blueprint (i.e. is a blueprint one copy of common conference=20 information, along with one template or can there be multiple=20 templates associated)?=20 The current wording in the framework supports the multiple=20 template proposal; again, per the text in 7.3 and the basic=20 definition of Blueprint. I couldn't initially see that we had an issue with=20 the framework per se. But, based on the discussion amongst the group of authors, it=20 became clear that a clarification in the FW would be useful,=20 although the viewpoints were fairly evenly split as to the need=20 for multiple templates (within a given blueprint). There was general agreement that a blueprint may have more than one template associated with it, however, one viewpoint was the templates can be defined in a way that include all the combinations (e.g., rather than a blueprint having separate templates for audio, video, text, they are provided a single multimedia template that combines the 3). Whereas, another viewpoint was that we should still have it as an option as to whether a client wants to choose multimedia or the audio, video and text separately (or some combination thereof). It was generally agreed that it's expeditious to define the combinations that seem reasonable into a single template. However, the alternative viewpoint was that the FW (at least) shouldn't preclude offering multiple templates in a given blueprint. With this approach, the blueprint can be viewed as having the superset that is allowed for the particular flavor of conference and then the client chooses and returns in the explicit reservation object what it wants to use, which is then validated by the conferencing system.=20 A compromise was eventually proposed and agreed, with the proposal to add some text into the framework (before the 3rd paragraph in section 7.3 - right after the text proposed for resolution of DP4/4.1) mentioning something like: "A typical blueprint is anticipated to consist of a single template, as the template approach allows for defining combinations of media types in a single template [ref]. However, a blueprint may contain more than one template depending upon the characteristics and configurations supported by a specific conferencing system. This approach allows a conferencing system to provide the clients with additional flexibility in selecting the type of conference they desire." Mary. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Sat Dec 24 09:10: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 1EqA6T-0002w2-4E; Sat, 24 Dec 2005 09:10:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EqA6R-0002vv-BY for xcon@megatron.ietf.org; Sat, 24 Dec 2005 09:10: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 JAA22590 for ; Sat, 24 Dec 2005 09:09:23 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EqA9f-0007nv-CB for xcon@ietf.org; Sat, 24 Dec 2005 09:13:52 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jBOE8KQw014537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Dec 2005 09:10:24 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id jBOE86hX015729; Sat, 24 Dec 2005 09:08:19 -0500 Message-ID: <43AD5648.60607@cs.columbia.edu> Date: Sat, 24 Dec 2005 15:08:08 +0100 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Mary Barnes Subject: Re: [XCON] DP4/4.1: Common Conference Information and Templates (in/out problem) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=XXII, Probability=22%, Report='OBFU_CLASS_OTHER_LOW 2.5, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 I'm concerned that we're adding too many related, but subtly, different inheritance concepts. I'm still not quite sure I understand blueprints, but as described below, this seems awfully close to the concept of inheritance of individual instances ("tree"). Thus, I wonder if the two concepts can't be unified. Essentially, a "blueprint" becomes the root of the inheritance tree. That way, we only have one dynamic (value) inheritance concept. This also makes it easy to create custom inheritance, such as "our weekly departmental meeting". It simply gets created from one of the system-defined 'blueprints'. Henning Mary Barnes wrote: > Hi all, > > There's been a group of us (XCON FW authors, current template authors > and data model authors) discussing this point and a couple of related > issues around the Common conference information, templates and > blueprints offline since the IETF meeting. We've come to tenuous > agreement amongst ourselves on a couple of aspects of this topic and > wanted to continue and complete the discussion with the WG. I'm > summarizing the issues and the changes proposed at this point to the > framework to accomodate current thinking. I've labeled the related > questions/topics we've discussed for convenience as DP4.2 and DP4.3 and > I'll post those in separate threads to facilitate tracking the issues. > Feedback would be appreciated - ideally supported by alternative and/or > additional text . > > Per discussion at the IETF-64, there still seemed to be some debate > (beyond the basic data model approach discussed in the "Call for > Consensus:Data model" thread initiated by Adam) on some fundamentals of > the model defined in the framework. Basically, this is the DP4 issue as > to whether the template is in the same object as the common conference > information (i.e. "in") or whether it is a separate object (i.e. "out"). > The framework has been based on the "in" concept barring any other > conclusion by the WG, noting that the current definition of blueprint is > quite explicit about this: > "A conference blueprint is a static conference > object within a conferencing system, which describes a typical > conference setting supported by the system. A conference > blueprint is the basis for creation of dynamic conference objects. > A system may maintain multiple blueprints, each comprised of the > common conference information, along with any number of > templates." > > The discussion amongst the group seemed to lead to it's not being an > in/out issue as much as it is either by-value or by-reference. It was > suggested that we just chooose by-value for now, but that wasn't deemed > practical in terms of the model put forth in the framework in terms of > lots of flexibility, with optionality of templates. We did (tenuously) > agree to support both. The Blueprint concept really requires that we > support by-reference, and that's consistent with the current approach > whereby the client fetches any templates from the server that it doesn't > understand. At the same time, a barebones system could initially just > support a few templates and by-value might make sense. But, again, I > think it's too limiting for the vision represented in the framework to > be the only option supported. > > At this time, we're proposing something like the following be added > after the 1st paragraph in 7.3 (where 7.3 is the "Advanced Example" > section that introduces the blueprint concept) supporting the concept of > by-value or by-reference. It might be useful to add more text including > some background for the context for using one or the other, as well: > "As defined within this framework, a blueprint is comprised of the > common conference information and one or more templates. The templates > within the blueprint can either be included by-value or by-reference > depending upon the system implementation." > > Mary. > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Sat Dec 24 09: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 1EqAAT-0003hw-GX; Sat, 24 Dec 2005 09: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 1EqAAS-0003hr-3N for xcon@megatron.ietf.org; Sat, 24 Dec 2005 09:14: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 JAA22960 for ; Sat, 24 Dec 2005 09:13:32 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EqADh-0007uN-ES for xcon@ietf.org; Sat, 24 Dec 2005 09:18:01 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jBOEELQw015798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 24 Dec 2005 09:14:37 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id jBOEEHWe015774; Sat, 24 Dec 2005 09:14:20 -0500 Message-ID: <43AD57BB.9040209@cs.columbia.edu> Date: Sat, 24 Dec 2005 15:14:19 +0100 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Mary Barnes Subject: Re: [XCON] DP4.3: Can a blueprint contain more than one template References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PORN_PHRASE_15_0 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 I have to admit that I find this far too complicated. I see no hope that implementors will either understand or implement this in any interoperable fashion. I think we can avoid this by concentrating on two inheritance models that depend on each other: - A "datatype" (class, static) model that inherits variables; this seems to be called templates, although C++ templates, which most implementors are familiar with, are something different yet again; - A "data" (dynamic) model that is reflected in the inheritance of specific values ("audio only, with Joe as moderator"). By its nature, this would be derived from one template since each template will have different variables, possibly with the same name, so it makes no sense to inherit from several. As noted in my previous email, the root of this tree would be a particular blueprint. A blueprint is then created just like any other conference. I'm probably still not following the terminology, but, if I may say so, that's a sign that others who are not document authors will be similarly confused. Henning Mary Barnes wrote: > DP4.3 Is there more than one template associated with a given > blueprint (i.e. is a blueprint one copy of common conference > information, along with one template or can there be multiple > templates associated)? > > The current wording in the framework supports the multiple > template proposal; again, per the text in 7.3 and the basic > definition of Blueprint. I couldn't initially see that we had an issue > with > the framework per se. > > But, based on the discussion amongst the group of authors, it > became clear that a clarification in the FW would be useful, > although the viewpoints were fairly evenly split as to the need > for multiple templates (within a given blueprint). There was general > agreement that a blueprint may have more than one template associated > with it, however, one viewpoint was the templates can be defined in a > way that include all the combinations (e.g., rather than a blueprint > having separate templates for audio, video, text, they are provided a > single multimedia template that combines the 3). Whereas, another > viewpoint was that we should still have it as an option as to whether a > client wants to choose multimedia or the audio, video and text > separately (or some combination thereof). It was generally agreed that > it's expeditious to define the combinations that seem reasonable into a > single template. However, the alternative viewpoint was that the FW (at > least) shouldn't preclude offering multiple templates in a given > blueprint. With this approach, the blueprint can be viewed as having the > superset that is allowed for the particular flavor of conference and > then the client chooses and returns in the explicit reservation object > what it wants to use, which is then validated by the conferencing > system. > > A compromise was eventually proposed and agreed, with the proposal to > add some text into the framework (before the 3rd paragraph in section > 7.3 - right after the text proposed for resolution of DP4/4.1) > mentioning something like: > "A typical blueprint is anticipated to consist of a single template, as > the template approach allows for defining combinations of media types in > a single template [ref]. However, a blueprint may contain more than one > template depending upon the characteristics and configurations supported > by a specific conferencing system. This approach allows a conferencing > system to provide the clients with additional flexibility in selecting > the type of conference they desire." > > Mary. > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Sat Dec 24 09:23:40 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 1EqAJA-0005Rk-Rz; Sat, 24 Dec 2005 09:23:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EqAJ9-0005Rf-6m for xcon@megatron.ietf.org; Sat, 24 Dec 2005 09:23: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 JAA23878 for ; Sat, 24 Dec 2005 09:22:31 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EqAMN-00089Q-NS for xcon@ietf.org; Sat, 24 Dec 2005 09:27:00 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jBOENBQw017614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 24 Dec 2005 09:23:35 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id jBOEN8Xb015782 for ; Sat, 24 Dec 2005 09:23:11 -0500 Message-ID: <43AD59CE.1070102@cs.columbia.edu> Date: Sat, 24 Dec 2005 15:23:10 +0100 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: xcon@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [XCON] Inheritance proposal 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 (Your spam filter will probably block this since these proposals usually come from certain African countries.) I would find the discussion more intelligible and maybe avoid talking past each other if the document authors or others could construct an example in their object-oriented language of choice, anything from Java to C# to PHP5, illustrating the concept. If we can't model this in one of the standard OO languages, implementation is likely to be difficult and conceptually confusing. If we need concepts that are not in mainstream OO languages, we are probably overshooting our target complexity. Henning _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Dec 28 10:32:50 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 1ErdII-0008Cm-3c; Wed, 28 Dec 2005 10:32:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErdIG-0008CS-5G for xcon@megatron.ietf.org; Wed, 28 Dec 2005 10:32:48 -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 KAA18882 for ; Wed, 28 Dec 2005 10:31:37 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErdMJ-00039y-A7 for xcon@ietf.org; Wed, 28 Dec 2005 10:36:59 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1ErdIO-0007iQ-K2; Wed, 28 Dec 2005 09:32:56 -0600 From: "Brian Rosen" To: "'Mary Barnes'" , Subject: RE: [XCON] DP4.2: Defining new templates Date: Wed, 28 Dec 2005 10:29:42 -0500 Message-ID: <015c01c60bc3$87a8c230$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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYIHrZ2puiNOKyuSUWfCpCZ+pq0aQDovrtw 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 So, I'm not sure I like this. Generally, I like some flexibility, so, generally, I hate saying "you can't". OTOH, we are talking about something that is primarily a user interface, about which I have a reasonable amount of experience. From that experience, I can say that a well designed client would NOT APPRECIATE hearing from a server that this particular server happens to have added a few dozen minor controls, and would the client please dynamically render them in addition to those carefully designed by a quality user interface designer to meet a specification. It is NOT a matter of saying, "well no one forces you to use those controls". As we all know, the likelihood is that, actually, it won't really work, in the sense that the user won't have a good experience, if the controls aren't rendered. If you want a good user experience, you don't have variations from server to server for a well designed client; they all work the same. For that reason, I think we are best to NOT have this flexibility. I've gone along with people who want to retain the ability for a client to connect to a server, discover that a conference uses a template it doesn't understand, and attempts to render a user interface for it. I think users will not like the result, but, hey, there might be a genius out there who can make it work. It doesn't stop a well designed client who implements the template from doing its work well. Allowing a server to dynamically add controls would. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Friday, December 23, 2005 7:12 PM To: xcon@ietf.org Subject: [XCON] DP4.2: Defining new templates One of the points we discussed was: DP4.2 Whether clients can dynamically use new templates or whether new templates require new SW in clients? The current wording in the framework supports the former proposal, specifically, section 7.3 currently states: "A client may need to query any templates in the blueprints that it doesn't understand and then make a decision on compatibility." Part of the confusion here (at least for me) is over what is meant by "new". There seemed to be unanimous agreement that a client can query a template that it doesn't currently have or has not previously used. That isn't the same thing as saying that templates can be dynamically created by a conferencing system. Per the framework, all the templates used by a conferencing system must be documented and registered. So, the discussion ended up being more around what could be changed within a template without requiring SW changes. After discussion, the group of authors seemed to agree that while modifications in the form of new controls added to elements of a template could be done without the need to register anything or define a new template, but adding new elements does require appropriate documentation and registration (i.e. a client can't be expected to understand new elements). To clarify this, we could reasonably add something like the following the 2nd paragraph in section 5.2, which introduces the template concept: "It should be possible to modify the controls within an element of an existing template, without defining a new template. The client can than attempt to render the modified element to make use of the potential new functionality. However, adding new elements does require defining an entirely new template as discussed in the previous paragraph." Mary _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Dec 28 10:49:22 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 1ErdYI-0002Xu-8i; Wed, 28 Dec 2005 10:49:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErdYG-0002Xj-N5 for xcon@megatron.ietf.org; Wed, 28 Dec 2005 10:49:20 -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 KAA20251 for ; Wed, 28 Dec 2005 10:48:10 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErdcL-0003Zy-7U for xcon@ietf.org; Wed, 28 Dec 2005 10:53:33 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1ErdYQ-0000KG-FE; Wed, 28 Dec 2005 09:49:30 -0600 From: "Brian Rosen" To: "'Mary Barnes'" , Subject: RE: [XCON] DP4.3: Can a blueprint contain more than one template Date: Wed, 28 Dec 2005 10:46:06 -0500 Message-ID: <016001c60bc5$d2aaa760$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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYIHsLY/d0M6P8ASWiJ3o4knd2DXwDpS4Fg 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 Please, no. Pretty please? Once again, I'm most interested in systems that work well for users. I want to be able to build clients and servers that interact well together, and provide a good user experience. To do that, the client can't get a surprise from a server (or vice versa, but I don't think that is at issue here). You can't say things like "...configurations supported by a specific conferencing system" and not get surprised. Most of us working on these things, which I think includes the people who proposed this text, have agreed that it won't work if we have a zillion templates; the chances of a server offering the template the client implements will be too low. Instead, we want a small number of well crafted templates that meet most people's needs, with the ability to have others that might exploit some new capabilities. This argues that you DON'T offer lots and lots of TinkerToy templates that you select from to assemble a client. Do it "once", do it "right", and most clients will work with most servers. Have this kind of open ended free for all, and the only thing that will work is the simplest, dumbest kind of conference. "Once" and "Right" are hard. You don't get relief by creating this kind of option. It gets harder to make good interoperable implementations, not easier. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Friday, December 23, 2005 7:13 PM To: xcon@ietf.org Subject: [XCON] DP4.3: Can a blueprint contain more than one template DP4.3 Is there more than one template associated with a given blueprint (i.e. is a blueprint one copy of common conference information, along with one template or can there be multiple templates associated)? The current wording in the framework supports the multiple template proposal; again, per the text in 7.3 and the basic definition of Blueprint. I couldn't initially see that we had an issue with the framework per se. But, based on the discussion amongst the group of authors, it became clear that a clarification in the FW would be useful, although the viewpoints were fairly evenly split as to the need for multiple templates (within a given blueprint). There was general agreement that a blueprint may have more than one template associated with it, however, one viewpoint was the templates can be defined in a way that include all the combinations (e.g., rather than a blueprint having separate templates for audio, video, text, they are provided a single multimedia template that combines the 3). Whereas, another viewpoint was that we should still have it as an option as to whether a client wants to choose multimedia or the audio, video and text separately (or some combination thereof). It was generally agreed that it's expeditious to define the combinations that seem reasonable into a single template. However, the alternative viewpoint was that the FW (at least) shouldn't preclude offering multiple templates in a given blueprint. With this approach, the blueprint can be viewed as having the superset that is allowed for the particular flavor of conference and then the client chooses and returns in the explicit reservation object what it wants to use, which is then validated by the conferencing system. A compromise was eventually proposed and agreed, with the proposal to add some text into the framework (before the 3rd paragraph in section 7.3 - right after the text proposed for resolution of DP4/4.1) mentioning something like: "A typical blueprint is anticipated to consist of a single template, as the template approach allows for defining combinations of media types in a single template [ref]. However, a blueprint may contain more than one template depending upon the characteristics and configurations supported by a specific conferencing system. This approach allows a conferencing system to provide the clients with additional flexibility in selecting the type of conference they desire." Mary. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Dec 28 11:04:06 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 1ErdmY-0006d0-FI; Wed, 28 Dec 2005 11:04:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErdmW-0006cq-NL for xcon@megatron.ietf.org; Wed, 28 Dec 2005 11:04:04 -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 LAA23721 for ; Wed, 28 Dec 2005 11:02:54 -0500 (EST) Received: from zrtps0kp.nortel.com ([47.140.192.56] helo=zrtps0kp.nortelnetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErdqZ-0004hs-9T for xcon@ietf.org; Wed, 28 Dec 2005 11:08:16 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jBSG3fJ21810; Wed, 28 Dec 2005 11:03:41 -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: [XCON] DP4/4.1: Common Conference Information and Templates (in/out problem) Date: Wed, 28 Dec 2005 10:03:41 -0600 Message-ID: Thread-Topic: [XCON] DP4/4.1: Common Conference Information and Templates (in/out problem) Thread-Index: AcYIk89OXknlqBu9Syu8rD2jEpY4/wDM4DQA From: "Mary Barnes" To: "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable 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 I think the objective is as you state in that everything in the end does get created from a blueprint (basic or customized). =20 We were debating how customizable are the templates - I guess I don't see the impact on the inheritance model. If there doesn't seem to be the need for this "by-reference" and multiple templates concept, then that does simplify things (but restricts future flexibility and applicability of the framework). I guess it might be reasonable at this point to suggest that the data model and associated protocols will only support the by-value and a single template model initially. [That seems to be what Brian Rosen is also arguing for in his response.] Mary -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Saturday, December 24, 2005 8:08 AM To: Barnes, Mary [RICH2:B601:EXCH] Cc: xcon@ietf.org Subject: Re: [XCON] DP4/4.1: Common Conference Information and Templates (in/out problem) I'm concerned that we're adding too many related, but subtly, different=20 inheritance concepts. I'm still not quite sure I understand blueprints, but as described=20 below, this seems awfully close to the concept of inheritance of=20 individual instances ("tree"). Thus, I wonder if the two concepts can't be unified. Essentially, a=20 "blueprint" becomes the root of the inheritance tree. That way, we only have one dynamic (value) inheritance concept. This=20 also makes it easy to create custom inheritance, such as "our weekly=20 departmental meeting". It simply gets created from one of the=20 system-defined 'blueprints'. Henning Mary Barnes wrote: > Hi all, >=20 > There's been a group of us (XCON FW authors, current template authors > and data model authors) discussing this point and a couple of related > issues around the Common conference information, templates and > blueprints offline since the IETF meeting. We've come to tenuous > agreement amongst ourselves on a couple of aspects of this topic and > wanted to continue and complete the discussion with the WG. I'm > summarizing the issues and the changes proposed at this point to the > framework to accomodate current thinking. I've labeled the related > questions/topics we've discussed for convenience as DP4.2 and DP4.3 and > I'll post those in separate threads to facilitate tracking the issues. > Feedback would be appreciated - ideally supported by alternative and/or > additional text .=20 >=20 > Per discussion at the IETF-64, there still seemed to be some debate > (beyond the basic data model approach discussed in the "Call for > Consensus:Data model" thread initiated by Adam) on some fundamentals of > the model defined in the framework. Basically, this is the DP4 issue as > to whether the template is in the same object as the common conference > information (i.e. "in") or whether it is a separate object (i.e. "out"). > The framework has been based on the "in" concept barring any other > conclusion by the WG, noting that the current definition of blueprint is > quite explicit about this: > "A conference blueprint is a static conference > object within a conferencing system, which describes a typical > conference setting supported by the system. A conference > blueprint is the basis for creation of dynamic conference objects. > A system may maintain multiple blueprints, each comprised of the > common conference information, along with any number of > templates." >=20 > The discussion amongst the group seemed to lead to it's not being an > in/out issue as much as it is either by-value or by-reference. It was > suggested that we just chooose by-value for now, but that wasn't deemed > practical in terms of the model put forth in the framework in terms of > lots of flexibility, with optionality of templates. We did (tenuously) > agree to support both. The Blueprint concept really requires that we > support by-reference, and that's consistent with the current approach > whereby the client fetches any templates from the server that it doesn't > understand. At the same time, a barebones system could initially just > support a few templates and by-value might make sense. But, again, I > think it's too limiting for the vision represented in the framework to > be the only option supported. =20 >=20 > At this time, we're proposing something like the following be added > after the 1st paragraph in 7.3 (where 7.3 is the "Advanced Example" > section that introduces the blueprint concept) supporting the concept of > by-value or by-reference. It might be useful to add more text including > some background for the context for using one or the other, as well: > "As defined within this framework, a blueprint is comprised of the > common conference information and one or more templates. The templates > within the blueprint can either be included by-value or by-reference > depending upon the system implementation."=20 >=20 > Mary. >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Dec 28 11:08: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 1ErdrE-0000xG-Jh; Wed, 28 Dec 2005 11:08:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErdrC-0000x4-W3 for xcon@megatron.ietf.org; Wed, 28 Dec 2005 11:08:55 -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 LAA25893 for ; Wed, 28 Dec 2005 11:07:44 -0500 (EST) Received: from zrtps0kn.nortel.com ([47.140.192.55] helo=zrtps0kn.nortelnetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErdvF-0005U5-Ru for xcon@ietf.org; Wed, 28 Dec 2005 11:13:07 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jBSG8gp29105; Wed, 28 Dec 2005 11:08:42 -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: [XCON] DP4.3: Can a blueprint contain more than one template Date: Wed, 28 Dec 2005 10:08:41 -0600 Message-ID: Thread-Topic: [XCON] DP4.3: Can a blueprint contain more than one template Thread-Index: AcYIlGR6wp7lLUs7RYqiCtTEP9tB/ADNAWTA From: "Mary Barnes" To: "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable 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 Per my response to your response on DP4.2, if the WG agrees that the single template per blueprint is the way to go, then that does simplify things. Basically, the additional text in the FW would be: "A blueprint consists of a single template, as the template approach allows for defining combinations of media types in a single template [ref]. Whether a blueprint needs to support multiple templates and the associated mechanism is FFS." Mary -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Saturday, December 24, 2005 8:14 AM To: Barnes, Mary [RICH2:B601:EXCH] Cc: xcon@ietf.org Subject: Re: [XCON] DP4.3: Can a blueprint contain more than one template I have to admit that I find this far too complicated. I see no hope that implementors will either understand or implement this in any=20 interoperable fashion. I think we can avoid this by concentrating on two inheritance models=20 that depend on each other: - A "datatype" (class, static) model that inherits variables; this seems to be called templates, although C++ templates, which most implementors=20 are familiar with, are something different yet again; - A "data" (dynamic) model that is reflected in the inheritance of=20 specific values ("audio only, with Joe as moderator"). By its nature,=20 this would be derived from one template since each template will have=20 different variables, possibly with the same name, so it makes no sense=20 to inherit from several. As noted in my previous email, the root of this tree would be a particular blueprint. A blueprint is then created just=20 like any other conference. I'm probably still not following the terminology, but, if I may say so,=20 that's a sign that others who are not document authors will be similarly confused. Henning Mary Barnes wrote: > DP4.3 Is there more than one template associated with a given=20 > blueprint (i.e. is a blueprint one copy of common conference=20 > information, along with one template or can there be multiple=20 > templates associated)?=20 >=20 > The current wording in the framework supports the multiple=20 > template proposal; again, per the text in 7.3 and the basic=20 > definition of Blueprint. I couldn't initially see that we had an issue > with=20 > the framework per se. >=20 > But, based on the discussion amongst the group of authors, it=20 > became clear that a clarification in the FW would be useful,=20 > although the viewpoints were fairly evenly split as to the need=20 > for multiple templates (within a given blueprint). There was general > agreement that a blueprint may have more than one template associated > with it, however, one viewpoint was the templates can be defined in a > way that include all the combinations (e.g., rather than a blueprint > having separate templates for audio, video, text, they are provided a > single multimedia template that combines the 3). Whereas, another > viewpoint was that we should still have it as an option as to whether a > client wants to choose multimedia or the audio, video and text > separately (or some combination thereof). It was generally agreed that > it's expeditious to define the combinations that seem reasonable into a > single template. However, the alternative viewpoint was that the FW (at > least) shouldn't preclude offering multiple templates in a given > blueprint. With this approach, the blueprint can be viewed as having the > superset that is allowed for the particular flavor of conference and > then the client chooses and returns in the explicit reservation object > what it wants to use, which is then validated by the conferencing > system.=20 >=20 > A compromise was eventually proposed and agreed, with the proposal to > add some text into the framework (before the 3rd paragraph in section > 7.3 - right after the text proposed for resolution of DP4/4.1) > mentioning something like: > "A typical blueprint is anticipated to consist of a single template, as > the template approach allows for defining combinations of media types in > a single template [ref]. However, a blueprint may contain more than one > template depending upon the characteristics and configurations supported > by a specific conferencing system. This approach allows a conferencing > system to provide the clients with additional flexibility in selecting > the type of conference they desire." >=20 > Mary. >=20 >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Wed Dec 28 11:19: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 1Ere1X-0007EQ-BM; Wed, 28 Dec 2005 11:19:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ere1W-0007E3-1G for xcon@megatron.ietf.org; Wed, 28 Dec 2005 11:19:34 -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 LAA01126 for ; Wed, 28 Dec 2005 11:18:23 -0500 (EST) Received: from zrtps0kn.nortel.com ([47.140.192.55] helo=zrtps0kn.nortelnetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ere5Z-00078m-0v for xcon@ietf.org; Wed, 28 Dec 2005 11:23:46 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jBSGJBp00010; Wed, 28 Dec 2005 11:19:12 -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: [XCON] Inheritance proposal Date: Wed, 28 Dec 2005 10:19:11 -0600 Message-ID: Thread-Topic: [XCON] Inheritance proposal Thread-Index: AcYIlgJQsq3rTEwZRAS3MX4EgMj3TADMM7lw From: "Mary Barnes" To: "Henning Schulzrinne" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable 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 I agree it might be useful to include an example in OO annotation of a how a template could be realized in this model (I'm assuming you're not asking for an overall change in approach to the framework document itself). Although, I think if we can agree the way forward on the issues, that would be more of an icing on the cake thing than a necessity. We can certainly add a placeholder in the document if others think that would be useful.=20 Mary -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Saturday, December 24, 2005 8:23 AM To: xcon@ietf.org Subject: [XCON] Inheritance proposal (Your spam filter will probably block this since these proposals usually come from certain African countries.) I would find the discussion more intelligible and maybe avoid talking=20 past each other if the document authors or others could construct an=20 example in their object-oriented language of choice, anything from Java=20 to C# to PHP5, illustrating the concept. If we can't model this in one=20 of the standard OO languages, implementation is likely to be difficult=20 and conceptually confusing. If we need concepts that are not in=20 mainstream OO languages, we are probably overshooting our target complexity. Henning _______________________________________________ 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 Dec 28 17:11: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 1ErjWA-0003Xq-VY; Wed, 28 Dec 2005 17:11:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErjW9-0003Xi-1l for xcon@megatron.ietf.org; Wed, 28 Dec 2005 17:11: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 RAA25656 for ; Wed, 28 Dec 2005 17:10:22 -0500 (EST) From: hgs@cs.columbia.edu Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErjaA-0007yL-OV for xcon@ietf.org; Wed, 28 Dec 2005 17:15:49 -0500 Received: from hydra.cs.columbia.edu (IDENT:VzeoXMEszI9mY+w5IdhesWAEvRHPkFwd@hydra.cs.columbia.edu [128.59.16.129]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id jBSMBMQw005764 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 28 Dec 2005 17:11:23 -0500 (EST) Received: from webmail.cs.columbia.edu (IDENT:YsnWVMJ+gZbXJxOQmadvV1oobMZ8jJvm@localhost [127.0.0.1]) by hydra.cs.columbia.edu (8.12.10/8.12.10) with SMTP id jBSMBCah012437; Wed, 28 Dec 2005 17:11:22 -0500 Received: from 194.230.234.145 (SquirrelMail authenticated user hgs) by webmail.cs.columbia.edu with HTTP; Wed, 28 Dec 2005 17:11:22 -0500 (EST) Message-ID: <1345.194.230.234.145.1135807882.squirrel@webmail.cs.columbia.edu> In-Reply-To: References: Date: Wed, 28 Dec 2005 17:11:22 -0500 (EST) Subject: RE: [XCON] Inheritance proposal To: "Mary Barnes" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-PerlMx-Spam: Gauge=X, Probability=10%, Report='PRIORITY_NO_NAME 0.716, NO_REAL_NAME 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_PRIORITY 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 1.2 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 8bit Cc: xcon@ietf.org, Henning Schulzrinne 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 I don't think I'm asking for a change in the document, just to make sure that the terminology and approach does not contradict or differ subtly from common OO conventions and terminology. Unfortunately, currently I'm not so sure about that. > I agree it might be useful to include an example in OO annotation of a > how a template could be realized in this model (I'm assuming you're not > asking for an overall change in approach to the framework document > itself). Although, I think if we can agree the way forward on the > issues, that would be more of an icing on the cake thing than a > necessity. We can certainly add a placeholder in the document if others > think that would be useful. > > Mary > > -----Original Message----- > From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of > Henning Schulzrinne > Sent: Saturday, December 24, 2005 8:23 AM > To: xcon@ietf.org > Subject: [XCON] Inheritance proposal > > > (Your spam filter will probably block this since these proposals usually > > come from certain African countries.) > > I would find the discussion more intelligible and maybe avoid talking > past each other if the document authors or others could construct an > example in their object-oriented language of choice, anything from Java > to C# to PHP5, illustrating the concept. If we can't model this in one > of the standard OO languages, implementation is likely to be difficult > and conceptually confusing. If we need concepts that are not in > mainstream OO languages, we are probably overshooting our target > complexity. > > Henning > > > _______________________________________________ > 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 Dec 29 05:57:27 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 1ErvTL-0006EE-G5; Thu, 29 Dec 2005 05:57:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErvTJ-0006E1-5A for xcon@megatron.ietf.org; Thu, 29 Dec 2005 05:57:25 -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 FAA06129 for ; Thu, 29 Dec 2005 05:56:14 -0500 (EST) Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErvXX-00077J-3Z for xcon@ietf.org; Thu, 29 Dec 2005 06:01:47 -0500 Received: from CarstenSR40 (pop-ls-18-2-dialup-203.freesurf.ch [194.230.187.203]) (user=hgs10 mech=LOGIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jBTAvEH3006017 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Dec 2005 05:57:20 -0500 (EST) Message-ID: <006001c60c66$a745e110$cbbbe6c2@CarstenSR40> From: "Henning" To: "Mary Barnes" References: Subject: Re: [XCON] DP4/4.1: Common Conference Information and Templates(in/out problem) Date: Thu, 29 Dec 2005 11:57:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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 Your note makes me worry that I still don't understand the template concept. I had earlier provided a brief definition of a template. Is that in agreement with yours? In short: Template = class definition (data types); blueprint = initial values (dynamic). Obviously, a blueprint only makes sense within a particular template. ----- Original Message ----- From: "Mary Barnes" To: "Henning Schulzrinne" Cc: Sent: Wednesday, December 28, 2005 5:03 PM Subject: RE: [XCON] DP4/4.1: Common Conference Information and Templates(in/out problem) >I think the objective is as you state in that everything in the end does > get created from a blueprint (basic or customized). > > We were debating how customizable are the templates - I guess I don't > see the impact on the inheritance model. If there doesn't seem to be > the need for this "by-reference" and multiple templates concept, then > that does simplify things (but restricts future flexibility and > applicability of the framework). I guess it might be reasonable at this > point to suggest that the data model and associated protocols will only > support the by-value and a single template model initially. [That seems > to be what Brian Rosen is also arguing for in his response.] > > Mary > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Saturday, December 24, 2005 8:08 AM > To: Barnes, Mary [RICH2:B601:EXCH] > Cc: xcon@ietf.org > Subject: Re: [XCON] DP4/4.1: Common Conference Information and Templates > (in/out problem) > > > I'm concerned that we're adding too many related, but subtly, different > inheritance concepts. > > I'm still not quite sure I understand blueprints, but as described > below, this seems awfully close to the concept of inheritance of > individual instances ("tree"). > > Thus, I wonder if the two concepts can't be unified. Essentially, a > "blueprint" becomes the root of the inheritance tree. > > That way, we only have one dynamic (value) inheritance concept. This > also makes it easy to create custom inheritance, such as "our weekly > departmental meeting". It simply gets created from one of the > system-defined 'blueprints'. > > Henning > > Mary Barnes wrote: >> Hi all, >> >> There's been a group of us (XCON FW authors, current template authors >> and data model authors) discussing this point and a couple of related >> issues around the Common conference information, templates and >> blueprints offline since the IETF meeting. We've come to tenuous >> agreement amongst ourselves on a couple of aspects of this topic and >> wanted to continue and complete the discussion with the WG. I'm >> summarizing the issues and the changes proposed at this point to the >> framework to accomodate current thinking. I've labeled the related >> questions/topics we've discussed for convenience as DP4.2 and DP4.3 > and >> I'll post those in separate threads to facilitate tracking the issues. >> Feedback would be appreciated - ideally supported by alternative > and/or >> additional text . >> >> Per discussion at the IETF-64, there still seemed to be some debate >> (beyond the basic data model approach discussed in the "Call for >> Consensus:Data model" thread initiated by Adam) on some fundamentals > of >> the model defined in the framework. Basically, this is the DP4 issue > as >> to whether the template is in the same object as the common conference >> information (i.e. "in") or whether it is a separate object (i.e. > "out"). >> The framework has been based on the "in" concept barring any other >> conclusion by the WG, noting that the current definition of blueprint > is >> quite explicit about this: >> "A conference blueprint is a static conference >> object within a conferencing system, which describes a typical >> conference setting supported by the system. A conference >> blueprint is the basis for creation of dynamic conference > objects. >> A system may maintain multiple blueprints, each comprised of the >> common conference information, along with any number of >> templates." >> >> The discussion amongst the group seemed to lead to it's not being an >> in/out issue as much as it is either by-value or by-reference. It was >> suggested that we just chooose by-value for now, but that wasn't > deemed >> practical in terms of the model put forth in the framework in terms of >> lots of flexibility, with optionality of templates. We did (tenuously) >> agree to support both. The Blueprint concept really requires that we >> support by-reference, and that's consistent with the current approach >> whereby the client fetches any templates from the server that it > doesn't >> understand. At the same time, a barebones system could initially just >> support a few templates and by-value might make sense. But, again, I >> think it's too limiting for the vision represented in the framework to >> be the only option supported. >> >> At this time, we're proposing something like the following be added >> after the 1st paragraph in 7.3 (where 7.3 is the "Advanced Example" >> section that introduces the blueprint concept) supporting the concept > of >> by-value or by-reference. It might be useful to add more text > including >> some background for the context for using one or the other, as well: >> "As defined within this framework, a blueprint is comprised of the >> common conference information and one or more templates. The > templates >> within the blueprint can either be included by-value or by-reference >> depending upon the system implementation." >> >> Mary. >> >> >> _______________________________________________ >> XCON mailing list >> XCON@ietf.org >> https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Dec 29 08:32: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 1ErxtB-0004KR-5g; Thu, 29 Dec 2005 08:32:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Erxt9-0004KD-3Q for xcon@megatron.ietf.org; Thu, 29 Dec 2005 08:32: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 IAA24865 for ; Thu, 29 Dec 2005 08:31:03 -0500 (EST) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErxxG-0004eo-I9 for xcon@ietf.org; Thu, 29 Dec 2005 08:36:36 -0500 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C23C21A5; Thu, 29 Dec 2005 14:31:52 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Dec 2005 14:31:52 +0100 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Dec 2005 14:31:52 +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 Date: Thu, 29 Dec 2005 14:31:50 +0100 Message-ID: Thread-Topic: Control protocol: synchronous "query" mechanism vs asynchronous "query" mechanism Thread-Index: AcX29iJbNO6NKL00SqCAp2CbFm/piwVgMnAg From: "Oscar Novo \(JO/LMF\)" To: "Henning Schulzrinne" X-OriginalArrivalTime: 29 Dec 2005 13:31:52.0501 (UTC) FILETIME=[3A95C650:01C60C7C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: XCON-IETF Subject: [XCON] Control protocol: synchronous "query" mechanism vs asynchronous "query" mechanism 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 Some weeks ago we submit the CSCP proposal draft. This proposal has a = mechanism to query the capabilities of the system using a synchronous = "query" mechanism. =20 Some time ago we discussed if developing a synchronous "query" mechanism = to query the capabilities of the system is a dubious utility or we = should use insteed an asynchronous "query" mechanism, the SIPPING = notification package (see message below). Still, we haven=B4t reached a = conclusion in this thread and it is still open. If we can agree the way = forward, the authors of CSCP can changes the text in the next version to = accomodate what we agree.=20 Still, I think we need a "asynchronous query" mechanism to query the = state of the conference and a "synchronous query" mechanism to query the = capabilities of the system. I don=B4t mean we should develop a = completely new XCON-specific mechanism for the "asynchronous query". We = can use the SIPPING notification package. With the implementation of an = "asynchronous query" mechanism in the conference control protocol, the = administrator can query the capabilities of the system when s/he wants = and the system doesn=B4t need to send periodically this information to = this users, saving bandwith and avoiding a bottleneck at signalling = level since the capabilities of the system usually change quickly. And being truth that asynchronous query mechanism is harder to implement = than the synchronous one (thank you Henning to clarify me this = question), I think the difference implementing one mechanism or other is = very small, for instance, in both mechanisms you have to deal with any = errors.=20 -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: 2. joulukuuta 2005 6:11 To: Oscar Novo (JO/LMF) Cc: br@brianrosen.net; Even, Roni; XCON-IETF Subject: Re: [XCON] Call for Consensus and Discussion: Data Model From a practical perspective, you can indeed get a SUBSCRIBE to tickle = a NOTIFY with the current state, but that seems far harder to program = than a synchronous "query" mechanism. Thus, while this does duplicate = mechanisms in a strict sense, the purpose and application is = sufficiently different that this seems less harmful than the = alternative. I would also argue that trying to develop an XCON-specific = publish/subscribe/notify mechanism seems of dubious utility unless = existing mechanisms are clearly incapable of handling the chore. One of = the nicer aspects of re-using the event mechanism is that a lot of the = tools, such as the privacy rules, can probably be drafted into service = fairly easily. That way, we don't have to develop new XML to restrict = who can get notified of conference events. Oscar Novo (JO/LMF) wrote: > Completely Agree with Brian. >=20 > The current conference event package represents just the state of the=20 > 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...). > Note that the "SIP Event Package for Conference State" already=20 > includes the posibility to send a "part of the conference object"=20 > state (Section > 4.4 Partial Notifications Mechanism).=20 >=20 > The conference control protocol we choose should have a mechanism to=20 > query the capabilities of the system (mixing policy, can non specified = > users join the conference or is the conference access allowed only to=20 > users pre-defined by the creator and so on). >=20 > Oscar >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Dec 29 08:49:47 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 1EryA6-0000qY-Vt; Thu, 29 Dec 2005 08:49:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EryA5-0000qL-I7 for xcon@megatron.ietf.org; Thu, 29 Dec 2005 08:49:45 -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 IAA26821 for ; Thu, 29 Dec 2005 08:48:33 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EryEL-0005E1-2g for xcon@ietf.org; Thu, 29 Dec 2005 08:54:09 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1EryA4-0005oA-Jt; Thu, 29 Dec 2005 07:49:45 -0600 From: "Brian Rosen" To: "'Henning'" , "'Mary Barnes'" Subject: RE: [XCON] DP4/4.1: Common Conference Information andTemplates(in/out problem) Date: Thu, 29 Dec 2005 08:46:13 -0500 Message-ID: <034501c60c7e$3ddb4270$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: <006001c60c66$a745e110$cbbbe6c2@CarstenSR40> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcYMZzIybMjYcXK1TheBLMyVNAiSUAAFn9Uw 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: 7bit Cc: xcon@ietf.org 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 FWIW, my conception of Blueprint is the same as Henning's. A template is a definition; there is a document that describes it, and probably something like a schema. The Blueprint is the set of initial values assigned to an object conformant to the schema. Brian -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Henning Sent: Thursday, December 29, 2005 5:57 AM To: Mary Barnes Cc: xcon@ietf.org Subject: Re: [XCON] DP4/4.1: Common Conference Information andTemplates(in/out problem) Your note makes me worry that I still don't understand the template concept. I had earlier provided a brief definition of a template. Is that in agreement with yours? In short: Template = class definition (data types); blueprint = initial values (dynamic). Obviously, a blueprint only makes sense within a particular template. ----- Original Message ----- From: "Mary Barnes" To: "Henning Schulzrinne" Cc: Sent: Wednesday, December 28, 2005 5:03 PM Subject: RE: [XCON] DP4/4.1: Common Conference Information and Templates(in/out problem) >I think the objective is as you state in that everything in the end does > get created from a blueprint (basic or customized). > > We were debating how customizable are the templates - I guess I don't > see the impact on the inheritance model. If there doesn't seem to be > the need for this "by-reference" and multiple templates concept, then > that does simplify things (but restricts future flexibility and > applicability of the framework). I guess it might be reasonable at this > point to suggest that the data model and associated protocols will only > support the by-value and a single template model initially. [That seems > to be what Brian Rosen is also arguing for in his response.] > > Mary > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Saturday, December 24, 2005 8:08 AM > To: Barnes, Mary [RICH2:B601:EXCH] > Cc: xcon@ietf.org > Subject: Re: [XCON] DP4/4.1: Common Conference Information and Templates > (in/out problem) > > > I'm concerned that we're adding too many related, but subtly, different > inheritance concepts. > > I'm still not quite sure I understand blueprints, but as described > below, this seems awfully close to the concept of inheritance of > individual instances ("tree"). > > Thus, I wonder if the two concepts can't be unified. Essentially, a > "blueprint" becomes the root of the inheritance tree. > > That way, we only have one dynamic (value) inheritance concept. This > also makes it easy to create custom inheritance, such as "our weekly > departmental meeting". It simply gets created from one of the > system-defined 'blueprints'. > > Henning > > Mary Barnes wrote: >> Hi all, >> >> There's been a group of us (XCON FW authors, current template authors >> and data model authors) discussing this point and a couple of related >> issues around the Common conference information, templates and >> blueprints offline since the IETF meeting. We've come to tenuous >> agreement amongst ourselves on a couple of aspects of this topic and >> wanted to continue and complete the discussion with the WG. I'm >> summarizing the issues and the changes proposed at this point to the >> framework to accomodate current thinking. I've labeled the related >> questions/topics we've discussed for convenience as DP4.2 and DP4.3 > and >> I'll post those in separate threads to facilitate tracking the issues. >> Feedback would be appreciated - ideally supported by alternative > and/or >> additional text . >> >> Per discussion at the IETF-64, there still seemed to be some debate >> (beyond the basic data model approach discussed in the "Call for >> Consensus:Data model" thread initiated by Adam) on some fundamentals > of >> the model defined in the framework. Basically, this is the DP4 issue > as >> to whether the template is in the same object as the common conference >> information (i.e. "in") or whether it is a separate object (i.e. > "out"). >> The framework has been based on the "in" concept barring any other >> conclusion by the WG, noting that the current definition of blueprint > is >> quite explicit about this: >> "A conference blueprint is a static conference >> object within a conferencing system, which describes a typical >> conference setting supported by the system. A conference >> blueprint is the basis for creation of dynamic conference > objects. >> A system may maintain multiple blueprints, each comprised of the >> common conference information, along with any number of >> templates." >> >> The discussion amongst the group seemed to lead to it's not being an >> in/out issue as much as it is either by-value or by-reference. It was >> suggested that we just chooose by-value for now, but that wasn't > deemed >> practical in terms of the model put forth in the framework in terms of >> lots of flexibility, with optionality of templates. We did (tenuously) >> agree to support both. The Blueprint concept really requires that we >> support by-reference, and that's consistent with the current approach >> whereby the client fetches any templates from the server that it > doesn't >> understand. At the same time, a barebones system could initially just >> support a few templates and by-value might make sense. But, again, I >> think it's too limiting for the vision represented in the framework to >> be the only option supported. >> >> At this time, we're proposing something like the following be added >> after the 1st paragraph in 7.3 (where 7.3 is the "Advanced Example" >> section that introduces the blueprint concept) supporting the concept > of >> by-value or by-reference. It might be useful to add more text > including >> some background for the context for using one or the other, as well: >> "As defined within this framework, a blueprint is comprised of the >> common conference information and one or more templates. The > templates >> within the blueprint can either be included by-value or by-reference >> depending upon the system implementation." >> >> Mary. >> >> >> _______________________________________________ >> XCON mailing list >> XCON@ietf.org >> https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > _______________________________________________ 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 Dec 29 09:24:48 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 1Eryi0-0001LK-7K; Thu, 29 Dec 2005 09:24:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eryhx-0001LF-Kz for xcon@megatron.ietf.org; Thu, 29 Dec 2005 09:24:46 -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 JAA00364 for ; Thu, 29 Dec 2005 09:23:33 -0500 (EST) Received: from dx28.winwebhosting.com ([70.85.77.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErymD-0006lo-Pd for xcon@ietf.org; Thu, 29 Dec 2005 09:29:10 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by dx28.winwebhosting.com with esmtpa (Exim 4.52) id 1Eryi2-00018t-RP; Thu, 29 Dec 2005 08:24:51 -0600 From: "Brian Rosen" To: "'Oscar Novo \(JO/LMF\)'" , "'Henning Schulzrinne'" Date: Thu, 29 Dec 2005 09:22:35 -0500 Message-ID: <034d01c60c83$51fa8720$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <62B89492B130A740A48CEE3227174D9D023632ADDE@stntexch04.cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcX29iJbNO6NKL00SqCAp2CbFm/piwVgMnAgAALKoKA= 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: quoted-printable Cc: 'XCON-IETF' Subject: [XCON] RE: Control protocol: synchronous "query" mechanism vs asynchronous "query" mechanism 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 Oscar I am confused. If you explicitly send a query, and get a response relatively = immediately, then that is synchronous. To explicitly query the state of the = conference, you use a synchronous query. An asynchronous mechanism is used when you don't know when something "interesting" happens. In this context, "interesting" is some kind of change of state of the conference. You use an asynchronous query to = find out that some state changed shortly after it changes, without an = explicit query. We don't need to use SIPPING events to tell us the state of the = conference. We need it to tell us when some kinds of state change. =20 To find out the state, I would want to just read some or all of the = object. CSCP would have to provide a way to do that. You send some kind of = request, and you get some kind of response relatively immediately. I imagine the request identifies what part of the object you want returned, and the response has that part of the object. I believe the issue is: how do you specify what "part of the object" = means? You could make it simple: you have one query =3D=3D return the entire = object. I suspect you want something more complex that that, so you can ask "who = are the holders of all of the floors right now?" Brian -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]=20 Sent: Thursday, December 29, 2005 8:32 AM To: Henning Schulzrinne Cc: br@brianrosen.net; XCON-IETF Subject: Control protocol: synchronous "query" mechanism vs asynchronous "query" mechanism Some weeks ago we submit the CSCP proposal draft. This proposal has a mechanism to query the capabilities of the system using a synchronous "query" mechanism. =20 Some time ago we discussed if developing a synchronous "query" mechanism = to query the capabilities of the system is a dubious utility or we should = use insteed an asynchronous "query" mechanism, the SIPPING notification = package (see message below). Still, we haven=B4t reached a conclusion in this = thread and it is still open. If we can agree the way forward, the authors of = CSCP can changes the text in the next version to accomodate what we agree.=20 Still, I think we need a "asynchronous query" mechanism to query the = state of the conference and a "synchronous query" mechanism to query the capabilities of the system. I don=B4t mean we should develop a = completely new XCON-specific mechanism for the "asynchronous query". We can use the = SIPPING notification package. With the implementation of an "asynchronous query" mechanism in the conference control protocol, the administrator can = query the capabilities of the system when s/he wants and the system doesn=B4t = need to send periodically this information to this users, saving bandwith and avoiding a bottleneck at signalling level since the capabilities of the system usually change quickly. And being truth that asynchronous query mechanism is harder to implement than the synchronous one (thank you Henning to clarify me this = question), I think the difference implementing one mechanism or other is very small, = for instance, in both mechanisms you have to deal with any errors.=20 -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: 2. joulukuuta 2005 6:11 To: Oscar Novo (JO/LMF) Cc: br@brianrosen.net; Even, Roni; XCON-IETF Subject: Re: [XCON] Call for Consensus and Discussion: Data Model From a practical perspective, you can indeed get a SUBSCRIBE to tickle = a NOTIFY with the current state, but that seems far harder to program than = a synchronous "query" mechanism. Thus, while this does duplicate = mechanisms in a strict sense, the purpose and application is sufficiently different = that this seems less harmful than the alternative. I would also argue that trying to develop an XCON-specific publish/subscribe/notify mechanism seems of dubious utility unless = existing mechanisms are clearly incapable of handling the chore. One of the nicer aspects of re-using the event mechanism is that a lot of the tools, such = as the privacy rules, can probably be drafted into service fairly easily. = That way, we don't have to develop new XML to restrict who can get notified = of conference events. Oscar Novo (JO/LMF) wrote: > Completely Agree with Brian. >=20 > The current conference event package represents just the state of the=20 > 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...). > Note that the "SIP Event Package for Conference State" already=20 > includes the posibility to send a "part of the conference object"=20 > state (Section > 4.4 Partial Notifications Mechanism).=20 >=20 > The conference control protocol we choose should have a mechanism to=20 > query the capabilities of the system (mixing policy, can non specified = > users join the conference or is the conference access allowed only to=20 > users pre-defined by the creator and so on). >=20 > Oscar >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Dec 30 14:45:04 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 1EsQBU-0000rm-7Q; Fri, 30 Dec 2005 14:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsQBS-0000qn-66 for xcon@megatron.ietf.org; Fri, 30 Dec 2005 14:45:02 -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 OAA01923 for ; Fri, 30 Dec 2005 14:43:48 -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 1EsQFw-000712-2l for xcon@ietf.org; Fri, 30 Dec 2005 14:49:40 -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 jBUJf8r19053; Fri, 30 Dec 2005 14:41:09 -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: [XCON] DP4/4.1: Common Conference Information andTemplates(in/out problem) Date: Fri, 30 Dec 2005 13:44:38 -0600 Message-ID: Thread-Topic: [XCON] DP4/4.1: Common Conference Information andTemplates(in/out problem) Thread-Index: AcYMZzIybMjYcXK1TheBLMyVNAiSUAAFn9UwAD48vPA= From: "Mary Barnes" To: , "Henning" X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Content-Transfer-Encoding: quoted-printable 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 I'm concerned that we may not all be on the same page. I generally agree with Brian's and Henning's statements. The clarification I would add is that the Blueprint also contains the Common Conference Information, so it's more than just a set of initial values assigned to an object conformant to the schema defined for the template. The blueprint also contains the intial values and ranges for the elements defined by the common conference information schema.=20 If there's agreement that the blueprint also contains common conference information, then we need to figure out where we need to clarify the text in the framework document so that everyone reading the document understands that and we also need to add text to emphasize the point you two have made. I agree the current definition of Blueprint is slightly fuzzy on the relationship between the template and the blueprint. Perhaps, changing the last sentence of the definition would help. So, I would propose a change from: "A system may maintain multiple blueprints, each comprised of the common conference information, along with any number of templates." to: "A system may maintain multiple blueprints. Each blueprint is=20 comprised of the initial values and ranges for the elements in=20 the object, conformant to the data schemas for the common=20 conference information and the specific template(s) associated=20 with the blueprint." If you both are saying that the Blueprint does not contain common conference information, then we need more discussion and input from others, as well, as alot more proposed text changes for the document.=20 Mary -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Thursday, December 29, 2005 7:46 AM To: 'Henning'; Barnes, Mary [RICH2:B601:EXCH] Cc: xcon@ietf.org Subject: RE: [XCON] DP4/4.1: Common Conference Information andTemplates(in/out problem) FWIW, my conception of Blueprint is the same as Henning's. A template is a definition; there is a document that describes it, and probably something like a schema. =20 The Blueprint is the set of initial values assigned to an object conformant to the schema.=20 Brian =20 -----Original Message----- From: xcon-bounces@ietf.org [mailto:xcon-bounces@ietf.org] On Behalf Of Henning Sent: Thursday, December 29, 2005 5:57 AM To: Mary Barnes Cc: xcon@ietf.org Subject: Re: [XCON] DP4/4.1: Common Conference Information andTemplates(in/out problem) Your note makes me worry that I still don't understand the template concept. I had earlier provided a brief definition of a template. Is that in=20 agreement with yours? In short: Template =3D class definition (data types); blueprint =3D = initial=20 values (dynamic). Obviously, a blueprint only makes sense within a=20 particular template. ----- Original Message -----=20 From: "Mary Barnes" To: "Henning Schulzrinne" Cc: Sent: Wednesday, December 28, 2005 5:03 PM Subject: RE: [XCON] DP4/4.1: Common Conference Information and=20 Templates(in/out problem) >I think the objective is as you state in that everything in the end does > get created from a blueprint (basic or customized). > > We were debating how customizable are the templates - I guess I don't > see the impact on the inheritance model. If there doesn't seem to be > the need for this "by-reference" and multiple templates concept, then > that does simplify things (but restricts future flexibility and > applicability of the framework). I guess it might be reasonable at this > point to suggest that the data model and associated protocols will only > support the by-value and a single template model initially. [That seems > to be what Brian Rosen is also arguing for in his response.] > > Mary > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Saturday, December 24, 2005 8:08 AM > To: Barnes, Mary [RICH2:B601:EXCH] > Cc: xcon@ietf.org > Subject: Re: [XCON] DP4/4.1: Common Conference Information and Templates > (in/out problem) > > > I'm concerned that we're adding too many related, but subtly, different > inheritance concepts. > > I'm still not quite sure I understand blueprints, but as described > below, this seems awfully close to the concept of inheritance of > individual instances ("tree"). > > Thus, I wonder if the two concepts can't be unified. Essentially, a > "blueprint" becomes the root of the inheritance tree. > > That way, we only have one dynamic (value) inheritance concept. This > also makes it easy to create custom inheritance, such as "our weekly > departmental meeting". It simply gets created from one of the > system-defined 'blueprints'. > > Henning > > Mary Barnes wrote: >> Hi all, >> >> There's been a group of us (XCON FW authors, current template authors >> and data model authors) discussing this point and a couple of related >> issues around the Common conference information, templates and >> blueprints offline since the IETF meeting. We've come to tenuous >> agreement amongst ourselves on a couple of aspects of this topic and >> wanted to continue and complete the discussion with the WG. I'm >> summarizing the issues and the changes proposed at this point to the >> framework to accomodate current thinking. I've labeled the related >> questions/topics we've discussed for convenience as DP4.2 and DP4.3 > and >> I'll post those in separate threads to facilitate tracking the issues. >> Feedback would be appreciated - ideally supported by alternative > and/or >> additional text . >> >> Per discussion at the IETF-64, there still seemed to be some debate >> (beyond the basic data model approach discussed in the "Call for >> Consensus:Data model" thread initiated by Adam) on some fundamentals > of >> the model defined in the framework. Basically, this is the DP4 issue > as >> to whether the template is in the same object as the common conference >> information (i.e. "in") or whether it is a separate object (i.e. > "out"). >> The framework has been based on the "in" concept barring any other >> conclusion by the WG, noting that the current definition of blueprint > is >> quite explicit about this: >> "A conference blueprint is a static conference >> object within a conferencing system, which describes a typical >> conference setting supported by the system. A conference >> blueprint is the basis for creation of dynamic conference > objects. >> A system may maintain multiple blueprints, each comprised of the >> common conference information, along with any number of >> templates." >> >> The discussion amongst the group seemed to lead to it's not being an >> in/out issue as much as it is either by-value or by-reference. It was >> suggested that we just chooose by-value for now, but that wasn't > deemed >> practical in terms of the model put forth in the framework in terms of >> lots of flexibility, with optionality of templates. We did (tenuously) >> agree to support both. The Blueprint concept really requires that we >> support by-reference, and that's consistent with the current approach >> whereby the client fetches any templates from the server that it > doesn't >> understand. At the same time, a barebones system could initially just >> support a few templates and by-value might make sense. But, again, I >> think it's too limiting for the vision represented in the framework to >> be the only option supported. >> >> At this time, we're proposing something like the following be added >> after the 1st paragraph in 7.3 (where 7.3 is the "Advanced Example" >> section that introduces the blueprint concept) supporting the concept > of >> by-value or by-reference. It might be useful to add more text > including >> some background for the context for using one or the other, as well: >> "As defined within this framework, a blueprint is comprised of the >> common conference information and one or more templates. The > templates >> within the blueprint can either be included by-value or by-reference >> depending upon the system implementation." >> >> Mary. >> >> >> _______________________________________________ >> XCON mailing list >> XCON@ietf.org >> https://www1.ietf.org/mailman/listinfo/xcon > > > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=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 Sat Dec 31 04:33:54 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 1Esd7a-0004Fy-N8; Sat, 31 Dec 2005 04:33:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Esd7Y-0004Fq-QB for xcon@megatron.ietf.org; Sat, 31 Dec 2005 04:33:53 -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 EAA19243 for ; Sat, 31 Dec 2005 04:32:39 -0500 (EST) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsdCA-000881-PM for xcon@ietf.org; Sat, 31 Dec 2005 04:38:40 -0500 Received: from CarstenSR40 (pop-mu-10-2-dialup-193.freesurf.ch [194.230.148.193]) (user=hgs10 mech=LOGIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id jBV9XiEM006452 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sat, 31 Dec 2005 04:33:48 -0500 (EST) Message-ID: <010201c60ded$53502790$c194e6c2@CarstenSR40> From: "Henning Schulzrinne" To: Date: Sat, 31 Dec 2005 10:33:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Subject: [XCON] New conference control draft: COMP 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 Just under the XCON chair wire, I submitted an I-D on using SOAP for conference control. Until it appears in the archives, you can find it at http://www.cs.columbia.edu/sip/draft/comp/draft-schulzrinne-xcon-comp-00.htmlI'm still working on the schema; there are a number of open issues, but Ihope it gets the flavor across:- HTTP/SOAP for manipulating objects, SIP for event notification- three core objects that can change representation based on namespaces- four core operations on these objects (get/create/change/delete)- a mechanism to find out server namespace support and declare namespaces asmust-know-to-playIn designing the protocol mechanics, it became clear that at least twoHTTP-based approaches are plausible: a SOAP-based approach, i.e., RPC, andusing HTTP GET/PUT/DELETE directly, sometimes known as HTTP+XML or REST. Thelatter is heading in the same general direction as XCAP, but I believe thatXCAP itself is sub-optimal for this application as it is tooXML-syntax-oriented.Henning _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon