From xcon-bounces@ietf.org Thu Jul 05 05:58:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6O6q-0001TG-W5; Thu, 05 Jul 2007 05:58:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6O6l-0001SW-Kl; Thu, 05 Jul 2007 05:58:43 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6O6e-0005CB-Tk; Thu, 05 Jul 2007 05:58:43 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4C33020515; Thu, 5 Jul 2007 11:58:36 +0200 (CEST) X-AuditID: c1b4fb3e-af032bb0000007e1-a6-468cc0cc8530 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 18E362023B; Thu, 5 Jul 2007 11:58:36 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 11:58:35 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 11:58:35 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 15A662465; Thu, 5 Jul 2007 12:58:35 +0300 (EEST) Message-ID: <468CC0CA.7040805@ericsson.com> Date: Thu, 05 Jul 2007 12:58:34 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Black_David@emc.com References: <4675044C.9040004@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2007 09:58:35.0331 (UTC) FILETIME=[0D505930:01C7BEEB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: fluffy@cisco.com, tsv-dir@ietf.org, ietf@ietf.org, xcon@ietf.org Subject: [XCON] Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04 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: , Errors-To: xcon-bounces@ietf.org Hi David, I have put together a new revision of the draft that addresses all your comments. Regarding your comment (1), I will send a note to the ADs so that they decide what to do. Until the draft appears in the archives, it can be fetched from: http://users.piuha.net/gonzalo/temp/draft-ietf-xcon-bfcp-connection-05.txt Thanks, Gonzalo Black_David@emc.com wrote: > Gonzalo, > > Most of this looks good; I have a few comments: > > (1) In the two places where there are general recommendations that > are not specific to BFCP (IP address selection and use of > SubjectAltName in certs in preference to Subject), it would > be good to note that these are general recommendations > that are not specific to BFCP, **but** please consult your > AD on whether and how to do this, as these are cross-area > issues in the IETF. The existing text is ok. > > (2) I would change the sentence about PBKDF2 key strengthening, > as the use of "security" is questionable: > > OLD: > Because such key derivation functions may incorporate > iteration functions for key strengthening they provide some > additional security against dictionary attacks. > NEW: > Because such key derivation functions may incorporate > iteration functions for key strengthening they provide some > additional protection against dictionary attacks by > increasing the amount of work that the attacker must perform. > > (3) Regarding the "obtain" language, I would make the following > change to explain why the attacks don't apply - > > OLD: > When the keys are randomly generated and of sufficient length, > these attacks do not obtain. > NEW: > When the keys are randomly generated and of sufficient length, > dictionary attacks are not effective because such keys are > highly unlikely to be in the attacker's dictionary. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: Sunday, June 17, 2007 5:52 AM >> To: Black, David >> Cc: ietf@ietf.org; xcon@ietf.org; tsv-dir@ietf.org; Cullen Jennings >> Subject: Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04 >> >> Hi David, >> >> thanks for your comments. Answers inline: >> >> Black_David@emc.com wrote: >>> I've reviewed this document as part of the transport area >>> directorate's ongoing effort to review key IETF documents. >>> These comments were written primarily for the transport >>> area directors, but are copied to the document's authors >>> for their information and to allow them to address any >>> issues raised. >>> >>> This is a relatively straightforward draft about how a >>> client opens a TCP connection to a BFCP server when it >>> has the server's transport address information. >>> >>> Section 3 ventures into the area of IP address selection - >>> it references RFC 3484 (which is good) and then goes on to >>> make additional comments and recommendations on usage and >>> state of deployment of the techniques specified in RFC 3484. >>> While there's nothing technically wrong with this text, the >>> additional comments and recommendations are not specific >>> to BFCP, and may belong in a more generic document. >> Given that such a generic document does not exist, we need to >> give these >> recommendations here. >> >> >>> Section 4 starts with "All BFCP entities implement TLS ..." >>> That is correct, as RFC 4582 requires this, but it would be >>> better to cite RFC 4582 as part of this statement, e.g., >>> "[RFC 4582] requires that all BFCP entities implement TLS ..." >> What about performing the following change? >> >> OLD: >> >> All BFCP entities implement TLS [7] and SHOULD use it in all their >> connections. >> >> NEW: >> >> [RFC 4582] requires that all BFCP entities implement TLS and > recommends >> that they use it in all their connections. >> >> >>> In the second paragraph of Section 4, I would change >>> "can request the use of TLS" to "SHOULD request the use >>> of TLS". >> OK, I will fix it. >> >>> Section 5.1 specifies that SubjectAltName identities in >>> certificates are to be preferred to Subject identities. >>> Is this specific to BFCP or more general? >> We got that recommendation from our security adviser. I do not know >> whether this will be documented in a generic document at some point. >> >>> The following text appears to be an oversight: >>> >>> If the client knows the server's IP address, the iPAddress >>> subjectAltName must be present in the certificate and must >>> exactly match the IP address known to the client. >>> >>> The client *always* knows the server's IP address (e.g., >>> DNS returns it). I think the intended case here is that >>> the client contacts the server using the server's IP address >>> and as a result does not know the server's hostname. Rephrasing >>> in that sort of fashion would also express a preference for >>> hostname as certificate identity, which I believe is desirable. >> What about performing the following change?: >> >> OLD: >> If the client knows the server's IP address, the iPAddress >> subjectAltName must be present in the certificate and must exactly >> match the IP address known to the client. >> >> NEW: >> If the client does not know the server's hostname and contacts the >> server directly using the server's IP address, the iPAddress >> subjectAltName must be present in the certificate and must exactly >> match the IP address known to the client. >> >> >>> Section 6 disturbingly shifts between "password" and >>> "pre-shared key" and appears to get a few things wrong in >>> the process. To begin with, the statement that "TLS PSK mode >>> is subject to offline dictionary attacks." is false when >>> the PSK is high-entropy. OTOH, it is correct when the PSK >>> is low-entropy (e.g., a password, or derived from a password >>> without introduction of additional entropy). The discussion >>> in Section 7.2 of RFC 4279 applies, especially the last >>> paragraph about PSK generation. The section needs to be >>> carefully revised to distinguish between "password" and >>> "pre-shared key", especially given the mention of use of >>> PBKDF2 to generate the latter from the former. >> what about performing the following change?: >> >> OLD: >> >> TLS PSK mode is subject to offline dictionary attacks. In DHE and >> RSA modes, an attacker who can mount a single man-in-the-middle >> attack on a client/server pair can then mount a dictionary attack > on >> the password. In modes without DHE or RSA, an attacker who can >> record communications between a client/server pair can mount a >> dictionary attack on the password. Accordingly, it is RECOMMENDED >> that where possible clients use certificate-based server >> authentication ciphersuites with PSK in order to defend against >> dictionary attacks. >> >> In addition, passwords SHOULD be chosen with enough entropy to >> provide some protection against dictionary attacks. Because the >> entropy of text varies dramatically and is generally far less than >> that of an equivalent random bitstring, no hard and fast rules > about >> password length are possible. However, in general passwords > SHOULD >> be chosen to be at least 8 characters and selected from a pool >> containing both upper and lower case, numbers, and special > keyboard >> characters (note that an 8-character ASCII password has a maximum >> entropy of 56 bits and in general far lower). FIPS PUB 112 [11] >> provides some guidance on the relevant issues. If possible, >> passphrases are preferable to passwords. In addition, a > cooperating >> client and server pair MAY choose to derive the TLS PSK shared key >> from the passphrase via a password-based key derivation function > such >> as PBKDF2 [2]. >> >> >> NEW: >> >> TLS PSK simply relies on a pre-shared key without specifying the >> nature of the key. In practice, such keys have two sources: text >> passwords and randomly generated binary keys. When keys are > derived >> from passwords, TLS PSK mode is subject to offline dictionary >> attacks. In DHE and RSA modes, an attacker who can mount a single >> man-in-the-middle attack on a client/server pair can then mount a >> dictionary attack on the password. In modes without DHE or RSA, an >> attacker who can record communications between a client/server > pair >> can mount a dictionary attack on the password. Accordingly, it is >> RECOMMENDED that where possible clients use certificate-based >> server authentication ciphersuites with password-derived PSKs, >> in order to defend against dictionary attacks. >> >> In addition, passwords SHOULD be chosen with enough entropy to >> provide some protection against dictionary attacks. Because the >> entropy of text varies dramatically and is generally far less than >> that of an equivalent random bitstring, no hard and fast rules > about >> password length are possible. However, in general passwords > SHOULD >> be chosen to be at least 8 characters and selected from a pool >> containing both upper and lower case, numbers, and special > keyboard >> characters (note that an 8-character ASCII password has a maximum >> entropy of 56 bits and in general far lower). FIPS PUB 112 [11] >> provides some guidance on the relevant issues. If possible, >> passphrases are preferable to passwords. In addition, a > cooperating >> client and server pair MAY choose to derive the TLS PSK shared key >> from the passphrase via a password-based key derivation function > such >> as PBKDF2 [2]. Because such key derivation functions may > incorporate >> iteration functions for key strengthening they provide some >> additional security against dictionary attacks. >> >> When the keys are randomly generated and of sufficient length, >> these attacks do not obtain. Where possible, keys SHOULD be >> generated using a strong random number generator as specified >> in RFC 4086 [REF]. A minimum key length of 80 bits SHOULD be used. >> >> >> Thanks, >> >> Gonzalo > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Jul 05 12:41:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6UOO-0001G5-QE; Thu, 05 Jul 2007 12:41:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6UOM-0001FZ-DP; Thu, 05 Jul 2007 12:41:18 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6UNC-0003VY-O4; Thu, 05 Jul 2007 12:41:18 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 05 Jul 2007 09:39:37 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAM66jEarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,504,1175497200"; d="scan'208"; a="177122264:sNHT73603566" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l65GdbUQ022592; Thu, 5 Jul 2007 09:39:37 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id l65GdZXI026925; Thu, 5 Jul 2007 16:39:35 GMT In-Reply-To: References: <4675044C.9040004@ericsson.com> <468CC0CA.7040805@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <792852CF-42D8-4282-8FE4-61F017DB78DA@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Thu, 5 Jul 2007 09:38:33 -0700 To: Black_David@emc.com X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=998; t=1183653577; x=1184517577; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20tsv-dir=20review=20of=20draft-ietf-xcon-bfcp-connecti on-04 |Sender:=20; bh=8d8YSXlgvJ0N7/698/ZDx+sww1L78jmy/l7hlKQaDXg=; b=j05fgwoYUghS7x2VLvFtGAuFLXmUq2hLDJIncFUl6vMiOXDPND6057uoEEFWENnFBXm+o4sq q7XFiPViC4VYz0+E3M4/knzGvtFkmvYnV9pOKb3naULORiaQtGybQTH6; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tsv-dir@ietf.org, xcon@ietf.org, Gonzalo.Camarillo@ericsson.com, ietf@ietf.org Subject: [XCON] Re: tsv-dir review of draft-ietf-xcon-bfcp-connection-04 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: , Errors-To: xcon-bounces@ietf.org David - I put this tracker as a note so we are sure the appropriate ADs don't miss it in IESG review. On Jul 5, 2007, at 6:57 AM, Black_David@emc.com wrote: > Gonzalo, > > The -05 draft looks fine, and I have no problem with leaving comment > (1) [whether to say something applicable beyond BFCP on the subjects > of IP address selection and use of SubjectAltName] to the discretion > of the ADs. > > Thanks, > --David > >> >> Black_David@emc.com wrote: >>> Gonzalo, >>> >>> Most of this looks good; I have a few comments: >>> >>> (1) In the two places where there are general recommendations that >>> are not specific to BFCP (IP address selection and use of >>> SubjectAltName in certs in preference to Subject), it would >>> be good to note that these are general recommendations >>> that are not specific to BFCP, **but** please consult your >>> AD on whether and how to do this, as these are cross-area >>> issues in the IETF. The existing text is ok. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Jul 05 18:16:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ZcS-0005v3-Sk; Thu, 05 Jul 2007 18:16:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Zc9-0004a4-0J; Thu, 05 Jul 2007 18:15:53 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6Zc8-0004xc-Pr; Thu, 05 Jul 2007 18:15:52 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 8D9AD2AC7C; Thu, 5 Jul 2007 22:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I6ZbK-0006H1-AN; Thu, 05 Jul 2007 18:15:02 -0400 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, 05 Jul 2007 18:15:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-bfcp-connection-05.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: , 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-05.txt Pages : 10 Date : 2007-7-5 This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. Client and server authentication are based on Transport Layer Security (TLS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-bfcp-connection-05.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-05.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-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-5170234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-bfcp-connection-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-bfcp-connection-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-5170234.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --NextPart-- From xcon-bounces@ietf.org Wed Jul 11 12:10:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8elN-0000vn-Mw; Wed, 11 Jul 2007 12:10:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8elM-0000uy-FD for xcon@ietf.org; Wed, 11 Jul 2007 12:10:00 -0400 Received: from mail44.opentransfer.com ([76.162.254.44]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I8el7-0004ci-8y for xcon@ietf.org; Wed, 11 Jul 2007 12:10:00 -0400 Received: (qmail 15787 invoked by uid 399); 11 Jul 2007 16:09:12 -0000 Received: from unknown (HELO ?192.168.0.40?) (24.107.197.43) by mail44.opentransfer.com with SMTP; 11 Jul 2007 16:09:12 -0000 Message-ID: <469500A6.3090207@sipstation.com> Date: Wed, 11 Jul 2007 11:09:10 -0500 From: Alan Johnston User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: xcon@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Adam Roach Subject: [XCON] Agenda Requests 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: , Errors-To: xcon-bounces@ietf.org All, Please submit your agenda requests for IETF-69 to myself and Adam. Include your name, topic, draft, and approximately how much time you would like. Thanks, Alan Johnston co-chair _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Jul 16 07:38:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAOuB-0003kC-Vo; Mon, 16 Jul 2007 07:38:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAOuA-0003ig-7R for xcon@ietf.org; Mon, 16 Jul 2007 07:38:18 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAOu9-0002Ph-Tl for xcon@ietf.org; Mon, 16 Jul 2007 07:38:18 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1C422206D5; Mon, 16 Jul 2007 13:38:01 +0200 (CEST) X-AuditID: c1b4fb3c-ae67bbb0000007e1-31-469b589972fa Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0F81220701; Mon, 16 Jul 2007 13:38:01 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 13:38:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Agenda Requests Date: Mon, 16 Jul 2007 13:36:20 +0200 Message-ID: In-Reply-To: <469500A6.3090207@sipstation.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Agenda Requests Thread-Index: AcfD1brsmMYxBSoASxWQJOaGqnSDRwDx7C/A References: <469500A6.3090207@sipstation.com> From: "Oscar Novo (JO/LMF)" To: "Alan Johnston" , X-OriginalArrivalTime: 16 Jul 2007 11:38:00.0461 (UTC) FILETIME=[C35A33D0:01C7C79D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Adam Roach 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: , Errors-To: xcon-bounces@ietf.org Hello, I haven't seen in the XCON Agenda any time for the XCON notification = event package. Are we not going to have any presentation about that? Thanks, Oscar=20 -----Original Message----- From: Alan Johnston [mailto:alan@sipstation.com]=20 Sent: 11. hein=E4kuuta 2007 19:09 To: xcon@ietf.org Cc: Adam Roach Subject: [XCON] Agenda Requests All, Please submit your agenda requests for IETF-69 to myself and Adam. =20 Include your name, topic, draft, and approximately how much time you = would like. Thanks, Alan Johnston co-chair _______________________________________________ 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 Jul 17 06:17:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAk7v-00011F-6x; Tue, 17 Jul 2007 06:17:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAk7u-0000wv-AR for xcon@ietf.org; Tue, 17 Jul 2007 06:17:54 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAk7t-0001nm-RJ for xcon@ietf.org; Tue, 17 Jul 2007 06:17:54 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4669B21E23; Tue, 17 Jul 2007 12:16:10 +0200 (CEST) X-AuditID: c1b4fb3e-af032bb0000007e1-b6-469c96ea8090 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1837A21E28; Tue, 17 Jul 2007 12:16:10 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 12:16:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 17 Jul 2007 12:14:28 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-srinivasan-xcon-eventpkg-extension-01 Thread-Index: AcfIW351R22CtxvQRiywN1c7hvzNRA== From: "Oscar Novo (JO/LMF)" To: , , X-OriginalArrivalTime: 17 Jul 2007 10:16:09.0663 (UTC) FILETIME=[7EB3A4F0:01C7C85B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Subject: [XCON] draft-srinivasan-xcon-eventpkg-extension-01 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="===============1438397384==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1438397384== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C85B.42591724" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C85B.42591724 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I've read the new version of draft-srinivasan-xcon-eventpkg-extension-01 (http://tools.ietf.org/wg/xcon/draft-srinivasan-xcon-eventpkg-extensions -01.txt). My opinion is that the draft is not enough clear yet. You start talking about "Partial notification limitations" without giving enough background of what it's the document about.=20 As well reading the document it's not clear for me that the 'application/xcon-conference-info+xml' MIME type supports all the new elements defined in the XCON data model. These words should be state clearly in some part of the document. =20 I also would state clearly in some part of the document the following sentence: "All subscribers and notifiers implementing the XCON event package MUST support the MIME media type 'application/conference-info+xml' defined in the SIPPING event packages and the MIME media type 'application/xcon-conference-info+xml' defined in this document." Thanks, Oscar ------_=_NextPart_001_01C7C85B.42591724 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-srinivasan-xcon-eventpkg-extension-01

Hello,

I've read the new version of = draft-srinivasan-xcon-eventpkg-extension-01 (http://tools.ietf.org/wg/xcon/draft-srinivasan-xcon-eventp= kg-extensions-01.txt). My = opinion is that the draft is not enough clear yet. You start talking = about "Partial notification limitations" without giving enough = background of what it's the document about.

As well reading the document it's not = clear for me that the 'application/xcon-conference-info+xml' MIME type = supports all the new elements defined in the XCON data model. These = words should be state clearly in some part of the document.  =

I also would state clearly in some part = of the document the following sentence:

"All subscribers and notifiers = implementing the XCON event package MUST support the MIME media type = 'application/conference-info+xml' defined in the SIPPING event packages = and the MIME media type 'application/xcon-conference-info+xml' defined = in this document."

Thanks,

Oscar

------_=_NextPart_001_01C7C85B.42591724-- --===============1438397384== 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 --===============1438397384==-- From xcon-bounces@ietf.org Wed Jul 18 22:28:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBLkP-0002d0-1Y; Wed, 18 Jul 2007 22:28:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBLkN-0002Vz-OY for xcon@ietf.org; Wed, 18 Jul 2007 22:28:07 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBLkK-0007R4-Cy for xcon@ietf.org; Wed, 18 Jul 2007 22:28:07 -0400 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLE00IV7MTK6S@szxga04-in.huawei.com> for xcon@ietf.org; Thu, 19 Jul 2007 10:27:20 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLE00KIWMTIDI@szxga04-in.huawei.com> for xcon@ietf.org; Thu, 19 Jul 2007 10:27:20 +0800 (CST) Received: from b47629c ([10.70.108.73]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLE00E42MTHN4@szxml03-in.huawei.com> for xcon@ietf.org; Thu, 19 Jul 2007 10:27:18 +0800 (CST) Date: Thu, 19 Jul 2007 10:27:17 +0800 From: paul Subject: [xcon] Question about draft-ietf-xcon-common-data-model-05 To: Oscar.Novo@ericsson.com Message-id: <003f01c7c9ac$53c9f210$496c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcfJrFMUVysG1oIWSrmjfdSBHUXUGg== X-Spam-Score: 1.2 (+) X-Scan-Signature: 4da339c42fe5be09fa120bb0fcc4a575 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: , Content-Type: multipart/mixed; boundary="===============0668793899==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0668793899== Content-type: multipart/alternative; boundary="Boundary_(ID_v1gz4KgOr/dSxtaGebErrQ)" This is a multi-part message in MIME format. --Boundary_(ID_v1gz4KgOr/dSxtaGebErrQ) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Hi Oscar I have a question on this draft. In chapter 4.4 it said: "The element represents a boolean action. If set to TRUE, the focus is instructed to accept the subscription to floor control events. If set to FALSE, the focus is instructed to reject the subscription. If this element is undefined, it has a default value of FALSE, causing the subscription to floor control events to be rejected." Does "subscription" here mean the SIP SUBSCRIBE request initiated subscription? However I know the BFCP protocol is used for floor control, and there is no concept of subscription. --Boundary_(ID_v1gz4KgOr/dSxtaGebErrQ) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT

Hi  Oscar

I have a question on this draft.

In chapter 4.4 it said:

   “The <allow-floor-events> element represents a boolean action.  If set

   to TRUE, the focus is instructed to accept the subscription to floor

   control events.  If set to FALSE, the focus is instructed to reject

   the subscription.  If this element is undefined, it has a default

   value of FALSE, causing the subscription to floor control events to

   be rejected.”

Does “subscription” here mean the SIP SUBSCRIBE request initiated subscription?

However I know the BFCP protocol is used for floor control, and there is no concept of subscription.

 

--Boundary_(ID_v1gz4KgOr/dSxtaGebErrQ)-- --===============0668793899== 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 --===============0668793899==-- From xcon-bounces@ietf.org Thu Jul 19 03:29:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBQS4-0005eq-Me; Thu, 19 Jul 2007 03:29:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBQS3-0005ek-51 for xcon@ietf.org; Thu, 19 Jul 2007 03:29:31 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBQS1-0006nk-U7 for xcon@ietf.org; Thu, 19 Jul 2007 03:29:30 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 4BF9F21118; Thu, 19 Jul 2007 09:29:29 +0200 (CEST) X-AuditID: c1b4fb3e-af032bb0000007e1-79-469f12d9a713 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 04ECE21526; Thu, 19 Jul 2007 09:29:29 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 09:29:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [xcon] Question about draft-ietf-xcon-common-data-model-05 Date: Thu, 19 Jul 2007 09:27:45 +0200 Message-ID: In-Reply-To: <003f01c7c9ac$53c9f210$496c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [xcon] Question about draft-ietf-xcon-common-data-model-05 Thread-Index: AcfJrFMUVysG1oIWSrmjfdSBHUXUGgAJEgfw References: <003f01c7c9ac$53c9f210$496c460a@china.huawei.com> From: "Oscar Novo (JO/LMF)" To: "paul" X-OriginalArrivalTime: 19 Jul 2007 07:29:28.0741 (UTC) FILETIME=[8A838D50:01C7C9D6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f3b9db08b8c0fe2301a77f547096e31 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: , Content-Type: multipart/mixed; boundary="===============2019785718==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============2019785718== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C9D6.4D1B9AAC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C9D6.4D1B9AAC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Paul, =20 Actually a conference participant has two methods to 'subscribe' himself = to the floor events. One method is using offer/answer exchange mechanism = (rfc3264) using SIP INVITE and BFCP parameters in the SDP (rfc4583). The = other method is a general authorization mechanism described in section 9 = of rfc4582 and in draft-ietf-xcon-bfcp-connection-05 draft. =20 When we talk about 'subscription' in chapter 4.4 we're talking about = those two connection methods. Future documentation may define additional = connection mechanisms. =20 Cheers, =20 Oscar =20 ________________________________ From: paul [mailto:baohongqing@huawei.com]=20 Sent: 19. hein=E4kuuta 2007 5:27 To: Oscar Novo (JO/LMF) Cc: xcon@ietf.org Subject: [xcon] Question about draft-ietf-xcon-common-data-model-05 Hi Oscar=20 I have a question on this draft. In chapter 4.4 it said: "The element represents a boolean action. If = set to TRUE, the focus is instructed to accept the subscription to floor control events. If set to FALSE, the focus is instructed to reject the subscription. If this element is undefined, it has a default value of FALSE, causing the subscription to floor control events to be rejected." Does "subscription" here mean the SIP SUBSCRIBE request initiated = subscription? However I know the BFCP protocol is used for floor control, and there is = no concept of subscription. =20 ------_=_NextPart_001_01C7C9D6.4D1B9AAC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Paul,
 
Actually a conference participant has two methods to = 'subscribe' himself=20 to the floor events. One method is using offer/answer exchange mechanism = (rfc3264) using SIP INVITE and BFCP parameters in the SDP (rfc4583). The = other=20 method is a general authorization mechanism described in section 9 = of=20 rfc4582 and in draft-ietf-xcon-bfcp-connection-05=20 draft.  
When=20 we talk about 'subscription' in chapter 4.4 we're talking about those = two=20 connection methods. Future documentation may define = additional=20 connection mechanisms.
 
Cheers,
 
Oscar
 
From: paul = [mailto:baohongqing@huawei.com]=20
Sent: 19. hein=E4kuuta 2007 5:27
To: Oscar Novo=20 (JO/LMF)
Cc: xcon@ietf.org
Subject: [xcon] Question = about=20 draft-ietf-xcon-common-data-model-05

Hi=20  Oscar

I have a = question=20 on this draft.

In = chapter 4.4 it=20 said:

   =93The=20 <allow-floor-events> element represents a boolean action.  If = set

   to=20 TRUE, the focus is instructed to accept the subscription to=20 floor

  =20 control events.  If set to FALSE, the focus is instructed to=20 reject

   the=20 subscription.  If this element is undefined, it has a=20 default

  =  value=20 of FALSE, causing the subscription to floor control events=20 to

   be=20 rejected.=94

Does=20 =93subscription=94 here mean the SIP SUBSCRIBE request initiated=20 subscription?

However = I know the=20 BFCP protocol is used for floor control, and there is no concept of=20 subscription.

 

------_=_NextPart_001_01C7C9D6.4D1B9AAC-- --===============2019785718== 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 --===============2019785718==-- From xcon-bounces@ietf.org Thu Jul 19 08:35:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVER-0004u2-GZ; Thu, 19 Jul 2007 08:35:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVEQ-0004tV-FY for xcon@ietf.org; Thu, 19 Jul 2007 08:35:46 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBVEO-0004vu-To for xcon@ietf.org; Thu, 19 Jul 2007 08:35:46 -0400 Received: from rly12b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly12b.srv.mailcontrol.com (MailControl) with ESMTP id l6JCZa2b002804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 Jul 2007 13:35:43 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly12b.srv.mailcontrol.com (MailControl) id l6JCZDRw032043 for xcon@ietf.org; Thu, 19 Jul 2007 13:35:13 +0100 Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly12b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id l6JCZBdu031898; Thu, 19 Jul 2007 13:35:12 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [xcon] Question about draft-ietf-xcon-common-data-model-05 Date: Thu, 19 Jul 2007 13:35:11 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [xcon] Question about draft-ietf-xcon-common-data-model-05 Thread-Index: AcfJrFMUVysG1oIWSrmjfdSBHUXUGgAJEgfwAAweliA= References: <003f01c7c9ac$53c9f210$496c460a@china.huawei.com> From: "Chris Boulton" To: "Oscar Novo \(JO/LMF\)" , "paul" X-Scanned-By: MailControl A-07-08-00 (www.mailcontrol.com) on 10.66.1.122 X-Spam-Score: -0.0 (/) X-Scan-Signature: 73f7847c44628482de9d5f1018acf469 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: , Content-Type: multipart/mixed; boundary="===============0677201929==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0677201929== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CA01.3F775288" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CA01.3F775288 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi Paul, =20 Actually a conference participant has two methods to 'subscribe' himself to the floor events. One method is using offer/answer exchange mechanism (rfc3264) using SIP INVITE and BFCP parameters in the SDP (rfc4583). The other method is a general authorization mechanism described in section 9 of rfc4582 and in draft-ietf-xcon-bfcp-connection-05 draft.=20=20 When we talk about 'subscription' in chapter 4.4 we're talking about those two connection methods. Future documentation may define additional connection mechanisms.=20 =20 [Chris Boulton] Oscar - it might be worth expanding this text to clearly state and reference the current subscription mechanisms (or point to the appropriate section). =20 Chris. =20 =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 distribut= ion is strictly prohibited. If you are not the addressee, please notify th= e sender immediately and destroy all copies of this email. Ubiquity Softwar= e Corporation plc, a company registered under the laws of England and Wales= , Registration 2719723, registered offices at Eastern Business Park, Buildi= ng 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom. ------_=_NextPart_001_01C7CA01.3F775288 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi Paul,

 

Actually a conference participant has two methods to 'subscribe' himself to the floor events. One method is using offer/answer exchange mechanism (rfc3264) using SIP INVITE and BFCP parameters in the SDP (rfc458= 3). The other method is a general authorization mechanism described in sec= tion 9 of rfc4582 and in draft-ietf-xcon-bfcp-connection-05 draft. &nb= sp;

When we talk about 'subscription' in chapter 4.4 we're talking about those two connection methods. Future documentation may define additional connection mechanisms. 

 <= /p>

[Chris Boulton] Oscar – it might = be worth expanding this text to clearly state and reference the current subscription mechanisms (or point to the appropriate section).

 

Chris.

 

 <= /p>



Information contained in this e-mail and any attachments are intended fo= r the use of the addressee only, and may contain confidential information o= f Ubiquity Software Corporation. All unauthorized use, disclosure or distri= bution is strictly prohibited. If you are not the addressee, please notify = the sender immediately and destroy all copies of this email. Ubiquity Softw= are Corporation plc, a company registered under the laws of England and Wal= es, Registration 2719723, registered offices at Eastern Business Park, Buil= ding 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom= .

 ------_=_NextPart_001_01C7CA01.3F775288-- --===============0677201929== 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 --===============0677201929==-- From xcon-bounces@ietf.org Thu Jul 19 08:42:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVKx-0003A1-M9; Thu, 19 Jul 2007 08:42:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBVKv-00039k-Ho for xcon@ietf.org; Thu, 19 Jul 2007 08:42:29 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBVKt-0005Ej-SN for xcon@ietf.org; Thu, 19 Jul 2007 08:42:29 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 51BFC212F1; Thu, 19 Jul 2007 14:42:27 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-fd-469f5c33135a Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 22DC320575; Thu, 19 Jul 2007 14:42:27 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 14:42:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [xcon] Question about draft-ietf-xcon-common-data-model-05 Date: Thu, 19 Jul 2007 14:40:43 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [xcon] Question about draft-ietf-xcon-common-data-model-05 Thread-Index: AcfJrFMUVysG1oIWSrmjfdSBHUXUGgAJEgfwAAweliAAAEUBkA== References: <003f01c7c9ac$53c9f210$496c460a@china.huawei.com> From: "Oscar Novo (JO/LMF)" To: "Chris Boulton" , "paul" X-OriginalArrivalTime: 19 Jul 2007 12:42:26.0484 (UTC) FILETIME=[42EBBF40:01C7CA02] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 73948e4d005645343fd08e813e5615ef 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: , Content-Type: multipart/mixed; boundary="===============0872063411==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0872063411== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CA02.05A17A44" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CA02.05A17A44 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable OK, I'll do that in the new version of the draft. =20 Thanks, =20 Oscar ________________________________ From: Chris Boulton [mailto:cboulton@ubiquity.net]=20 Sent: 19. hein=E4kuuta 2007 15:35 To: Oscar Novo (JO/LMF); paul Cc: xcon@ietf.org Subject: RE: [xcon] Question about draft-ietf-xcon-common-data-model-05 =20 Hi Paul, =20 Actually a conference participant has two methods to 'subscribe' himself = to the floor events. One method is using offer/answer exchange mechanism = (rfc3264) using SIP INVITE and BFCP parameters in the SDP (rfc4583). The = other method is a general authorization mechanism described in section 9 = of rfc4582 and in draft-ietf-xcon-bfcp-connection-05 draft. =20 When we talk about 'subscription' in chapter 4.4 we're talking about = those two connection methods. Future documentation may define additional = connection mechanisms.=20 =20 [Chris Boulton] Oscar - it might be worth expanding this text to clearly = state and reference the current subscription mechanisms (or point to the = appropriate section). =20 Chris. =20 =20 Information contained in this e-mail and any attachments are intended = for the use of the addressee only, and may contain confidential = information of Ubiquity Software Corporation. 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. Ubiquity Software Corporation plc, a company registered = under the laws of England and Wales, Registration 2719723, registered = offices at Eastern Business Park, Building 3, Wern Fawr Lane, St. = Mellons, Cardiff CF3 5EA, Wales, United Kingdom. ------_=_NextPart_001_01C7CA02.05A17A44 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
OK,=20 I'll do that in the new version of the draft.
 
Thanks,
 
Oscar

From: Chris Boulton=20 [mailto:cboulton@ubiquity.net]
Sent: 19. hein=E4kuuta 2007=20 15:35
To: Oscar Novo (JO/LMF); paul
Cc:=20 xcon@ietf.org
Subject: RE: [xcon] Question about=20 draft-ietf-xcon-common-data-model-05

 

Hi=20 Paul,

 

Actually a = conference=20 participant has two methods to 'subscribe' himself to the floor events. = One=20 method is using offer/answer exchange mechanism (rfc3264) using SIP = INVITE and=20 BFCP parameters in the SDP (rfc4583). The other method is a general=20 authorization mechanism described in section 9 of rfc4582 and = in=20 draft-ietf-xcon-bfcp-connection-05 = draft.  

When we talk = about=20 'subscription' in chapter 4.4 we're talking about those two connection=20 methods. Future documentation may define additional connection=20 mechanisms. 

 

[Chris=20 Boulton] Oscar =96 it might be worth expanding this text to clearly = state and=20 reference the current subscription mechanisms (or point to the = appropriate=20 section).

 

Chris.

 

 



Information contained in this e-mail and any attachments are intended = for the=20 use of the addressee only, and may contain confidential information of = Ubiquity=20 Software Corporation. All unauthorized use, disclosure or distribution = is=20 strictly prohibited. If you are not the addressee, please notify the = sender=20 immediately and destroy all copies of this email. Ubiquity Software = Corporation=20 plc, a company registered under the laws of England and Wales, = Registration=20 2719723, registered offices at Eastern Business Park, Building 3, Wern = Fawr=20 Lane, St. Mellons, Cardiff CF3 5EA, Wales, United=20 Kingdom.

 ------_=_NextPart_001_01C7CA02.05A17A44-- --===============0872063411== 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 --===============0872063411==-- From xcon-bounces@ietf.org Mon Jul 23 10:40:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICz5U-0004h0-Jh; Mon, 23 Jul 2007 10:40:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICz5T-0004gq-4I for xcon@ietf.org; Mon, 23 Jul 2007 10:40:39 -0400 Received: from mail7.exchange.microsoft.com ([131.107.1.27] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICz5S-0008Dq-Ps for xcon@ietf.org; Mon, 23 Jul 2007 10:40:39 -0400 Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.155) by DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft SMTP Server (TLS) id 8.1.154.1; Mon, 23 Jul 2007 07:40:38 -0700 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.8]) by df-bhd-02.exchange.corp.microsoft.com ([157.54.71.155]) with mapi; Mon, 23 Jul 2007 07:40:37 -0700 From: Srivatsa Srinivasan To: "Oscar Novo (JO/LMF)" , "srivatsa@microsoft.com" , "roni.even@polynom.co.il" , "xcon@ietf.org" Date: Mon, 23 Jul 2007 07:40:39 -0700 Thread-Topic: draft-srinivasan-xcon-eventpkg-extension-01 Thread-Index: AcfIW351R22CtxvQRiywN1c7hvzNRAE2iVsA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -104.0 (---------------------------------------------------) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [XCON] RE: draft-srinivasan-xcon-eventpkg-extension-01 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: , Errors-To: xcon-bounces@ietf.org Oscar, Thanks for the comments. Adding introductory text about the document should be easy. Regarding the s= econd comment, Section 6 (below) points out that the centralized data model= be used for this event package, but we can enforce that with normative tex= t. And the third comment is just a rewording of the second statement below = and the next revision will have it. "This document defines a new media type 'application/ xcon-conference-info+xml' for supporting the data model for centralized conferencing for which the XML schema (data format) is defined in [3]. Implementations MUST follow all sections of [2] not related directly to the data model. These include, but are not limited to, Section 3, Section 4 (see annotations below), Section 8 and Section 9.1." Regards, Srivatsa. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon Jul 23 19:12:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID74V-0000z2-Fv; Mon, 23 Jul 2007 19:12:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID74S-0000v8-1k; Mon, 23 Jul 2007 19:12:08 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID74R-0005El-Lb; Mon, 23 Jul 2007 19:12:07 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 7F9642AC3A; Mon, 23 Jul 2007 23:12:07 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ID74R-0001t2-3B; Mon, 23 Jul 2007 19:12:07 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 23 Jul 2007 19:12:07 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Internet Architecture Board , xcon mailing list , xcon chair , RFC Editor Subject: [XCON] Protocol Action: 'Connection Establishment in 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: , Errors-To: xcon-bounces@ietf.org The IESG has approved the following document: - 'Connection Establishment in 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 Cullen Jennings and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-bfcp-connection-05.txt Technical Summary This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. Client and server authentication are based on Transport Layer Security (TLS). Working Group Summary This document is a product of the XCON working group. Its contents have been uncontroversial in working group discussions. Document Quality Eric Rescorla reviewed the document from a security perspective. Based on his feedback, the client authentication mechanism was changed from one based loosely on HTTP digest authentication to the use of TLS with pre-shared keys. Adam Roach has reviewed the document for quality. Personnel Adam Roach is the Document Shepherd for this document. Cullen Jennings is the responsible Area Director. Note to RFC Editor OLD: If possible, passphrases are preferable to passwords. NEW: If possible, passphrases are preferable to passwords. It is RECOMMENDED that implementations support, at minimum, 16-character passwords or passphrases. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue Jul 24 06:06:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDHHE-0000T7-Qa; Tue, 24 Jul 2007 06:06:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDHHC-0000Sq-R9 for xcon@ietf.org; Tue, 24 Jul 2007 06:05:58 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDHHA-0001TU-TH for xcon@ietf.org; Tue, 24 Jul 2007 06:05:58 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLO00G4EHCUCS@szxga03-in.huawei.com> for xcon@ietf.org; Tue, 24 Jul 2007 18:05:18 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLO00257HCTAZ@szxga03-in.huawei.com> for xcon@ietf.org; Tue, 24 Jul 2007 18:05:18 +0800 (CST) Received: from b47629c ([10.70.108.73]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLO00FJ9HCS73@szxml04-in.huawei.com> for xcon@ietf.org; Tue, 24 Jul 2007 18:05:17 +0800 (CST) Date: Tue, 24 Jul 2007 18:05:16 +0800 From: paul Subject: [xcon] Comments on draft-ietf-xcon-common-data-model To: oscar.novo@ericsson.com Message-id: <000801c7cdda$227a6640$496c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcfN1/s6SUvktOZVRpqZz0kWW0ysBwAAgh4Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 8279e2b0006e70acac79ca9454596384 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: , Content-Type: multipart/mixed; boundary="===============0563195585==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0563195585== Content-type: multipart/alternative; boundary="Boundary_(ID_YA6sbb5WoH1/G59jct87Kw)" This is a multi-part message in MIME format. --Boundary_(ID_YA6sbb5WoH1/G59jct87Kw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Oscar and all, As RFC4575 describes an event package about conference state, and this document extends it and introduces new elements including floor information among others. How about we add Claim Queue information to Floor Information? I know there was a draft that contains this info. , its name is draft-wu-sipping-floor-control. We can also discuss alternatives to gain this purpose, such as extending BFCP, or even defining a new event package. Cheers, Paul --Boundary_(ID_YA6sbb5WoH1/G59jct87Kw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Oscar and all,

 

As RFC4575 describes an event package about conference state, and this document extends it and introduces new elements including floor information among others. How about we add Claim Queue information to Floor Information? I know there was a draft that contains this info. , its name is draft-wu-sipping-floor-control.

We can also discuss alternatives to gain this purpose, such as extending BFCP, or even defining a new event package.

 

Cheers,

Paul

--Boundary_(ID_YA6sbb5WoH1/G59jct87Kw)-- --===============0563195585== 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 --===============0563195585==-- From xcon-bounces@ietf.org Tue Jul 24 10:46:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLeY-00069K-K8; Tue, 24 Jul 2007 10:46:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLeW-000696-WE for xcon@ietf.org; Tue, 24 Jul 2007 10:46:21 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDLeV-0000Or-UK for xcon@ietf.org; Tue, 24 Jul 2007 10:46:20 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3CF0521308; Tue, 24 Jul 2007 16:46:19 +0200 (CEST) X-AuditID: c1b4fb3e-af833bb0000007e1-7a-46a610ba1aa3 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id C225421344; Tue, 24 Jul 2007 16:46:18 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 16:46:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [xcon] Comments on draft-ietf-xcon-common-data-model Date: Tue, 24 Jul 2007 16:44:31 +0200 Message-ID: In-Reply-To: <000801c7cdda$227a6640$496c460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [xcon] Comments on draft-ietf-xcon-common-data-model Thread-Index: AcfN1/s6SUvktOZVRpqZz0kWW0ysBwAAgh4QAAmReoA= References: <000801c7cdda$227a6640$496c460a@china.huawei.com> From: "Oscar Novo (JO/LMF)" To: "paul" X-OriginalArrivalTime: 24 Jul 2007 14:46:18.0447 (UTC) FILETIME=[64C80DF0:01C7CE01] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 94ddbad0060c343c23e74ba9bbebbccf 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: , Content-Type: multipart/mixed; boundary="===============1811366678==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1811366678== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CE01.250E0174" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CE01.250E0174 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Paul, =20 BFCP already implements a floor notification mechanism using the = FloorQuery/FloorStatus messages. =20 =20 Cheers, =20 Oscar ________________________________ From: paul [mailto:baohongqing@huawei.com]=20 Sent: 24. hein=E4kuuta 2007 13:05 To: Oscar Novo (JO/LMF) Cc: xcon@ietf.org Subject: [xcon] Comments on draft-ietf-xcon-common-data-model Hi Oscar and all,=20 =20 As RFC4575 describes an event package about conference state, and this = document extends it and introduces new elements including floor = information among others. How about we add Claim Queue information to = Floor Information? I know there was a draft that contains this info. , = its name is draft-wu-sipping-floor-control.=20 We can also discuss alternatives to gain this purpose, such as extending = BFCP, or even defining a new event package.=20 =20 Cheers, Paul ------_=_NextPart_001_01C7CE01.250E0174 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 Paul,
 
BFCP=20 already implements a floor notification mechanism using=20 the FloorQuery/FloorStatus messages.  <= /DIV>
 
Cheers,
 
Oscar

From: paul = [mailto:baohongqing@huawei.com]=20
Sent: 24. hein=E4kuuta 2007 13:05
To: Oscar Novo=20 (JO/LMF)
Cc: xcon@ietf.org
Subject: [xcon] Comments = on=20 draft-ietf-xcon-common-data-model

Hi Oscar = and all,=20

 

As = RFC4575=20 describes an event package about conference state, and this document = extends it=20 and introduces new elements including floor information among others. = How about=20 we add Claim Queue information to Floor Information? I know there was a = draft=20 that contains this info. , its name is draft-wu-sipping-floor-control.=20

We can = also=20 discuss alternatives to gain this purpose, such as extending BFCP, or = even=20 defining a new event package.

 

Cheers,

Paul

------_=_NextPart_001_01C7CE01.250E0174-- --===============1811366678== 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 --===============1811366678==-- From xcon-bounces@ietf.org Wed Jul 25 16:39:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDndr-0005E2-R9; Wed, 25 Jul 2007 16:39:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDndq-0005DF-PM for xcon@ietf.org; Wed, 25 Jul 2007 16:39:30 -0400 Received: from nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net ([2001:470:1f03:267::2] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDndp-0003wU-Fj for xcon@ietf.org; Wed, 25 Jul 2007 16:39:30 -0400 Received: from dhcp-11b9.ietf69.org (dhcp-11b9.ietf69.org [130.129.17.185]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6PKdNOR026373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Jul 2007 15:39:24 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46A7B4FB.10900@nostrum.com> Date: Wed, 25 Jul 2007 15:39:23 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: XCON-IETF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.17.185 is authenticated by a trusted mechanism) X-Spam-Score: -1.4 (-) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [XCON] Agenda Addition 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: , Errors-To: xcon-bounces@ietf.org Sorry for the late change -- we have added an agenda item to discuss some issues relating to Srivatsa's proposed conference event package (draft-srinivasan-xcon-eventpkg-extension-01). /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Jul 26 16:43:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEAAr-0006dW-5u; Thu, 26 Jul 2007 16:43:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEAAp-0006dP-NG for xcon@ietf.org; Thu, 26 Jul 2007 16:43:03 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEAAo-0000H0-AC for xcon@ietf.org; Thu, 26 Jul 2007 16:43:03 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 506AD200FE for ; Thu, 26 Jul 2007 22:43:01 +0200 (CEST) X-AuditID: c1b4fb3e-b1837bb0000007e1-ff-46a907556145 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3086B2007B for ; Thu, 26 Jul 2007 22:43:01 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 22:43:01 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 22:43:00 +0200 Received: from [131.160.126.192] (rvi2-126-192.lmf.ericsson.se [131.160.126.192]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 37D4B2342 for ; Thu, 26 Jul 2007 23:43:00 +0300 (EEST) Message-ID: <46A90753.6020506@ericsson.com> Date: Thu, 26 Jul 2007 23:42:59 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: XCON Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2007 20:43:01.0089 (UTC) FILETIME=[8E938D10:01C7CFC5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [XCON] Discussions on carrying floor control stuff in SIP 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: , Errors-To: xcon-bounces@ietf.org Hi, the discussions we talked about in the XCON session today are documented in the minutes of the SIPPING meeting in Washington DC on November 2004: http://www3.ietf.org/proceedings/04nov/sipping.html Topic: Event Package for Floor-related Information Discussions led by: Eunsook Kim Relevant documents: draft-ekim-sipping-conf-floor-package-00.txt Discussions will continue in XCON. More use cases are needed to understand the need of an alternative mechanism to fetch floor control information (BFCP already provides this information). You can fetch the draft under discussion at: http://www.watersprings.org/pub/id/draft-ekim-sipping-conf-floor-package-01.txt Cheers, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Jul 26 18:51:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IECBV-0000ym-2T; Thu, 26 Jul 2007 18:51:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IECBT-0000yb-Ee for xcon@ietf.org; Thu, 26 Jul 2007 18:51:51 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IECBT-0001kq-5S for xcon@ietf.org; Thu, 26 Jul 2007 18:51:51 -0400 Received: from dhcp-11b9.ietf69.org (dhcp-11b9.ietf69.org [130.129.17.185]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l6QMpoqD013314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Jul 2007 17:51:50 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <46A92586.4000709@nostrum.com> Date: Thu, 26 Jul 2007 17:51:50 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: XCON-IETF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.17.185 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [XCON] Draft Minutes X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org I have uploaded the raw (draft) minutes from XCON to the IETF web site: http://www3.ietf.org/proceedings/07jul/minutes/xcon.txt If you have any comments, corrections, or clarifications, please let me know within the next week. /a _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon