From xcon-bounces@ietf.org Tue May 01 05:22:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HioZR-0001f8-4N; Tue, 01 May 2007 05:22:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HioLg-0002SZ-HO for xcon@ietf.org; Tue, 01 May 2007 05:08:40 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HioLf-0005P2-3i for xcon@ietf.org; Tue, 01 May 2007 05:08:40 -0400 Received: from rly31b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly31b.srv.mailcontrol.com (MailControl) with ESMTP id l4198Pwf009577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 May 2007 10:08:31 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly31b.srv.mailcontrol.com (MailControl) id l41984hO008780 for xcon@ietf.org; Tue, 1 May 2007 10:08:04 +0100 Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly31b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id l4197vvT008500; Tue, 01 May 2007 10:08:04 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 May 2007 10:07:57 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More comments on draft-ietf-xcon-framework-07.txt Thread-Index: AceHPwmeREeU/PqhQJ2OLBJG23H9ywALOemwARhM2gA= From: "Chris Boulton" To: "Mary Barnes" , "Oscar Novo \(JO/LMF\)" , X-Scanned-By: MailControl A-06-00-00 (www.mailcontrol.com) on 10.66.1.141 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1661445bbc0c3d9a6461fbf65ea80015 Cc: Subject: [XCON] RE: More comments on draft-ietf-xcon-framework-07.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: , Content-Type: multipart/mixed; boundary="===============0230856086==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0230856086== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78BD0.35BF0400" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78BD0.35BF0400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 [Chris Boulton] some comments in-line. =20 Chris. =20 =20 Hi Oscar, =20 Thanks for your comments. My responses are below [MB].=20=20 =20 Mary=20 -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]=20 Sent: Wednesday, April 25, 2007 8:38 AM To: xcon@ietf.org Cc: Barnes, Mary (RICH2:AR00); cboulton@ubiquitysoftware.com Subject: More comments on draft-ietf-xcon-framework-07.txt And here a bit more comments on the framework:=20 -The framework defines the data model as a "common conference information". When we had the templates this concept was right but now I think this concept is not correct. I propose to change the name to "Conference Information Data Model" as is defined in the data model draft.=20 [MB] Given we're post-WGLC, I'd prefer to have additional feedback before making this change as I think the Common Conference Information is a general enough concept and I think that change impacts a whole lot of text and I'd be concerned that I'd break more than I might fix with that change. [/MB] [Chris Boulton] While I can see what Oscar is saying I agree with Mary. At the end of the day this is STILL common information that is shared by all conference instances. The fact that we no longer have templates is irrelevant - it just changes the context slightly. I would keep it as is. - I think section 5.1 is a bit messy. It still have concepts about the templates. I have re-written a bit that section to adapted it to the data model idea:=20=20 =09=20 New centralized conferencing specifications can extend the conference information data model type as defined in [17] and introduce additional data elements to be used within the conference information data model type." - In the 'conferencing scenario realizations' section when a user "Alice" creates a sidebar conference. Is "Alice" included in the sidebar conference as a user? Reading the text looks like "Alice" is included in the sidebar but checking the figures looks like she is not part of the sidebar conference.=20=20 [MB] I'm not sure which figure you're referring to. In Figures 12 and 13, I guess we could debate whether "Alice" should show up in the Reservation, but "Alice" is shown in the "Active Sidebar Conference" in both Figures. Is that the figures you're referring to? [/MB]=20 - I'm a bit confuse with the use case explain in section 9.6 'Whispering or Private Messages'. As I understood whispering is a participant who send a one-way message to a single participant. RFC 4597 defines whispers or private messages as follow: "A participant can send a one-way message (text, audio, or even some other media) to another participant that is immediately rendered. This differs from a sidebar in that it is immediate and creates no long-lived session." The framework is defining whispering in a different way: "one participant sends a message to multiple participants using sidebars". For me, that definition is not connect to 'whispering or private messages' but instead to 'sidebars'.=20=20 [MB] No, I don't think the framework really defines the whispering in a different way - it does further refine that definition in the context of the fraamework. We define "whisper" in section 4 as: "A whisper involves a one-time media input to a specific participant(s) within a specific conference instance, accomplished using a sidebar. An example of a whisper would be an announcement injected only to the conference chair or to a new participant joining a conference." So, I think that's consistent with the definition in 4597 in that, per the example, the sidebar is immediately removed after delivering that onetime media.=20=20 [Chris Boulton] Agreed. As background, the definition was added in the -05, with other text added to the document on whisper added in the -03 based on WG discussions. I'd have to dig to find those threads, but am reluctant to re-open past discussions without additional input from others in the WG. [/MB] [Chris Boulton] Agreed. As well, the use case defined in 9.6 is very confused. Why do we need to create a sidebar and a conference ID to send a single private message to a user? It doesn't make any sense for me. If the participant knows the userID, he could send the whispering message straight to his friend without create any sidebar, conferenceID or notification message. [MB] This use case was added in the -05 version based on input from a WG member and is consistent with the WG consensus on the definition of whisper (which is based on a sidebar) and as I'm recalling we did have this long, long debate. [/MB] [Chris Boulton] Also agreed. - Section 9.9 'Observing and Coaching'. Is it necesary to create a sidebar for observing a conference? Couldn't be the observer in the conference a 'hidden' participant? As far as you notify the other participant that the conference is recorded or observed by a third party I guess it's OK, right?=20 [MB] And, that's exactly what the text says - you can accomplish the observing functionality by just having the supervisor as a hidden participant, which is what the first two paragraphs of that section discuss. It then describes that to take that functionality one step further to handle the coaching: " Taking the supervisor capability one step further introduces a scenario whereby the agent can hear the supervisor, as well as the customer. The customer can still only hear the agent. This scenario would involve the creation of a sidebar involving the agent and the supervisor. " [/MB]=20 - I think the intended status of the framework should be Standard track, no informational as it is now.=20=20 [MB] Agreed, per previous email discussions - I'll make that change with other nits and add that categorization to the header. [/MB] [Chris Boulton] Agreed. =09 - The user identifier and the XCON identifier are defined now in the data model. The references to those draft should be removed from the Framework or should reference to the data model instead.=20 [MB] Agreed per discussions at IETF-68. Nits:=20=20 [MB] Thanks - I'll take care of these on the next update.=20=20 In some places you are using "signaling" in other "signalling".=20 Figure 2: Change "Common conference information type" for "Conference Information Data Model type"=20 Figure 10: It's missing the clients usernames "Carol" and "Bob". Figure 13: When Alice creates the sidebar only includes one "confUserID". She should include at least "Bob", "Ethel" and "Carol" user ID. Figure 16: No sidebars are created in this uses case. So, "Active Sidebar Conference" should be change in the picture to "Active Conference". =09=20 Change in the text:=20 Cbject -> Object=20 Identifer-> Identifier=20 "And the the conference object is updated" -> "And the conference object is updated"=20 "Object identifier as as shown in Figure 11" -> "Object identifier as shown in Figure 11"=20 "can be handled by by supervisor adding" -> "can be handled by supervisor adding"=20 Cheers,=20 Oscar Novo=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_01C78BD0.35BF0400 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

 

 

[Chris Boulton] some comments in-line.=

 

Chris.

 

 

= Hi Oscar,

 

= Thanks for your comments. My responses are below [MB]. 

 

= Mary

-----Original Message-----
From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]
Sent: We= dnesday, April 25, 2007 8:38 AM
To: xcon@ietf.org
Cc: Barnes, Mary (RICH2:AR00= ); cboulton@ubiquitysoftware.com
Subject: More comments on draft-ietf-xcon-framework-07.txt

And here a= bit more comments on the framework:

-The framework defines the data model as a "common conference information". When we had the templates this concept was right but now I think this concept is not correct. I propose to change the name to "Conference Information Data Model" as is defi= ned in the data model draft. = ;

[MB] Given we're post-WGLC, I'd prefer to have additional feedback before making this change as I think the Common Conference Informa= tion is a general enough concept and I think that change impacts a whole lot of = text and I'd be concerned that I'd break more than I might fix with that change.= &n= bsp;[/MB]

[Chris Bou= lton] While I can see what Oscar is saying I agree with Mary.  At the end of= the day this is STILL common information that is shared by all conference instances.  The fact that we no longer have templates is irrelevant &#= 8211; it just changes the context slightly.  I would keep it as is.

- I think section 5.1 is a bit messy. It still ha= ve concepts about the templates. I have re-written a bit that section to adapt= ed it to the data model idea:  

 

New centralized conferencing specifications can extend the conference information data model type as defined in [17] and introduce additional data elements to be used within the conference informa= tion data model type."

- In the 'conferencing scenario realizations' sec= tion when a user "Alice" creates a sidebar conference. Is "Alice" included in the sidebar conference as a user? Reading the text looks like "Alice" is included in the sidebar but checking t= he figures looks like she is not part of the sidebar conference.  <= /p>

[MB] = &n= bsp;I'm not sure which figure you're re= ferring to.  In Figures 12 and 13, I guess we could debate whether "Alice" should show up in the Reservation, but "Alice&q= uot; is shown in the "Active Sidebar Conference" in both Figures. Is t= hat the figures you're referring to? [/MB] 

- I'm a bit confuse with the use case explain in section 9.6 'Whispering or Private Messages'. As I understood whispering is= a participant who send a one-way message to a single participant. RFC 4597 defines whispers or private messages as follow:

"A participant can send a one-way message (t= ext, audio, or even some other media) to another participant that is immediately rendered.  This differs from a sidebar in that it is immediate and cre= ates no long-lived session."

The framework is defining whispering in a differe= nt way: "one participant sends a message to multiple participants using sidebars". For me, that definition is not connect to 'whispering or private messages' but instead to 'sidebars'.  

[MB] No, I don't th= ink the framework really defines the whispering in a different way - it does further refine that definition in the context of the fraamework. We de= fine "whisper" in section 4 as:

   &= nbsp;  "A whisper involves a one-time media input to a specific
      participant(s) within a specific conference instance, accomplished
      using a sidebar.  An example of a whisp= er would be an announcement
      injected only to the conference chair or to a new participant
      joining a conference."

So, I think that's consistent with the definition in 4597 in that, per the example, the sideba= r is immediately removed after delivering that onetime media. 

[Chris Bou= lton] Agreed.

As background, the definition was added in the -05, with other text added to the document on whisper added in the -03 based on WG discussions. I'd have to dig to find t= hose threads, but am reluctant to re-open past discussions without additional in= put from others in the WG.  [/MB]

[Chris Bou= lton] Agreed.

As well, the use case defined in 9.6 is very confused. Why do we need to create a sidebar and a conference ID to send a single private message to a user? It doesn't make any sense for me. If the participant knows the userID, he could send the whispering message straight= to his friend without create any sidebar, conferenceID or notification message= . <= /p>

[MB] This use = case was added in the -05 version based on input from a WG member and is consistent with the WG consensus on the definition of whisper (which is bas= ed on a sidebar) and as I'm recalling we did have this long, long debate. [/MB= ]

[Chris Bou= lton] Also agreed.

 - Section 9.9 'Observing and Coaching'. Is = it necesary to create a sidebar for observing a conference? Couldn't be the observer in the conference a 'hidden' participant? As far as you notify the other participant that the conference is recorded or observed by a third pa= rty I guess it's OK, right? =

[MB] And, that's exactly what the text says - you can accomplish the observ= ing functionality by just having the supervisor as a hidden participa= nt, which is what the first two paragraphs of that section discuss. It then describes that to take that functionality one step further to handle the coaching:

  " Taking the supervisor capability one step further introduces a
   scenario whereby the agent can hear the supervisor, as well as= the
   customer.  The customer can still only hear the agent.&nb= sp; This scenario
   would involve the creation of a sidebar involving the agent and the
   supervisor. "

[/MB]= &n= bsp;

- I think the intended status of the framework sh= ould be Standard track, no informational as it is now. <= span style=3D'color:blue'> 

[MB] Agreed, per previous email discussions - I'll make t= hat change with other nits and add that categorization to the header.  [/M= B]

[Chris Bou= lton] Agreed.


- The user identifier and the XCON identifier are defined now in the data model. The references to those draft should be removed from the Framew= ork or should reference to the data model instead. 

[MB] Agreed per discussions at IETF-68.

Nits: =  

[MB] Thanks - = I'll take care of these on the next update.  

In some places you are using "signaling"= ; in other "signalling".

Figure 2: Change "Common conference informat= ion type" for "Conference Information Data Model type"
Figure 10: It's missing the clients usernames "Carol" and "Bob"= ;.
Figure 13: When Alice creates the sidebar only includes one "confUserID". She should include at least "Bob", "Ethel" and "Carol" user ID.

Figure 16: No sidebars are created in this uses c= ase. So, "Active Sidebar Conference" should be change in the picture to "Active Conference".

 

Change in the text:

Cbject -> Object
Identifer-> Identifier
"And the the conference object is updated" -> "And the conference object is updated"
"Object identifier as as shown in Figure 11" -> "Object identifier as shown in Figure 11"
"can be handled by by supervisor adding" -> "can be handled by supervisor adding"

Cheers,

Oscar Novo



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_01C78BD0.35BF0400-- --===============0230856086== 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 --===============0230856086==-- From xcon-bounces@ietf.org Tue May 01 05:31:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hiohc-0001Iw-Nz; Tue, 01 May 2007 05:31:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HioRI-00041V-Aj for xcon@ietf.org; Tue, 01 May 2007 05:14:28 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HioRH-0006Yj-Oc for xcon@ietf.org; Tue, 01 May 2007 05:14:28 -0400 Received: from rly04b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly04b.srv.mailcontrol.com (MailControl) with ESMTP id l419EH31009833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 May 2007 10:14:23 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly04b.srv.mailcontrol.com (MailControl) id l419DPeh006928 for xcon@ietf.org; Tue, 1 May 2007 10:13:25 +0100 Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly04b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id l419DHHv006510; Tue, 01 May 2007 10:13:25 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [XCON] RE: Comments on draft-ietf-xcon-framework-07.txt Date: Tue, 1 May 2007 10:13:17 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] RE: Comments on draft-ietf-xcon-framework-07.txt Thread-Index: AceGbX/I3u+pY8rARlmnn/lG3DIDfQAO3UwQAUnTKEA= From: "Chris Boulton" To: "Mary Barnes" , "Gonzalo Camarillo" X-Scanned-By: MailControl A-06-00-00 (www.mailcontrol.com) on 10.66.1.114 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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: , Errors-To: xcon-bounces@ietf.org [Chris Boulton] Some more comments in-line. Hi Gonzalo, Thanks for your comments - responses are embedded below [MB]. Mary -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Sent: Tuesday, April 24, 2007 7:39 AM To: XCON Cc: Barnes, Mary (RICH2:AR00) Subject: Comments on draft-ietf-xcon-framework-07.txt Hi, a few comments on the XCON framework. The title of the framework, the abstract, and several sections, state=20 that this document defines a data model for centralized conferencing.=20 This is confusing because the framework does not actually define the=20 data model; the data model draft does. Therefore, I would suggest that=20 the framework clearly states that the definition of the data model is in the data model draft. The document has a section (Section 2) that references RFC 2119 but then does not use normative language. If the idea is to have an informational framework, that section can be removed. The 1st paragraph of Section 5 states that the common conference=20 information type is extensible for including multiple sub-type. What=20 exactly does that mean? Extensions to the data model will continue using the same media type. [MB] Good catch. That is a leftover from the removal of the template concepts. I think it should just read: "The common conference information type is extensible." [/MB] [Chris Boulton] Agreed. The 2nd paragraph of Section 5.2 says that policies are not explicitly=20 defined within the data model, but rather are reflected in the system=20 realization. Given that policies will be studied after the data model is completed, I would avoid talking to much about policies until we have a=20 clear view on how they will be implemented. [MB] I agree that much of that section no longer fits based on the discussion from IETF-68 (and this also impacts the last paragraph of section 5). [Chris Boulton] I agree with this - it would even be worth referencing that this is subject to future study and work by the XCON WG. This will help avoid confusion. Did we ever take that point to the mailing list as a conclusion or does anyone have any concerns about removing this whole section and munging section 5.1 into section 5 and having only a general statement about policy? I'll take this item as an issue to the mailing list, as I don't think many people are going to read it here :) [/MB] Section 7.1 describes the cloning tree. Part of that concept is the=20 cloning of policies. Again, since policies are for further study, I=20 would avoid talking too much about them at this point. In fact, this=20 cloning tree concept will probably need to be further described in the=20 policies draft to be written in the future. [MB] I still think we need this parent enforceable concept here, no matter how we implement the policies. I think this is one of the reasons why I was one of the ones that did not want to remove all the policy data from the data model (i.e., I think some of the basic read/write and allowed sort of stuff may be necessary). Again, I'll take this point as part of the discussion of the issue to the list. [/MB] Nits: [MB] I'll fix these in the -08. [/MB] Page 5, 3rd paragraph. OLD: A Binary Floor Control Protocol (BFCP)... NEW: A floor control protocol (e.g., BFCP)... Figure 1: spacing problem on the right-most vertical line (which is made of dots). Figure 2: the same type of spacing problem. Cheers, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon 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. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue May 01 05:32:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hioiw-00040k-JF; Tue, 01 May 2007 05:32:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HioY7-0007lJ-Me for xcon@ietf.org; Tue, 01 May 2007 05:21:31 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HioY7-0007ek-00 for xcon@ietf.org; Tue, 01 May 2007 05:21:31 -0400 Received: from rly13b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly13b.srv.mailcontrol.com (MailControl) with ESMTP id l419LNab030880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 May 2007 10:21:27 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly13b.srv.mailcontrol.com (MailControl) id l419KOST027923 for xcon@ietf.org; Tue, 1 May 2007 10:20:24 +0100 Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly13b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id l419KKp4027359; Tue, 01 May 2007 10:20:24 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 May 2007 10:20:20 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More comments on draft-ietf-xcon-framework-07.txt Thread-Index: AceHPwmeREeU/PqhQJ2OLBJG23H9ywALOemwAOICnhAACayuQAAtyhhA From: "Chris Boulton" To: "Mary Barnes" , "Oscar Novo \(JO/LMF\)" , X-Scanned-By: MailControl A-07-07-00 (www.mailcontrol.com) on 10.66.1.123 X-Spam-Score: 0.0 (/) X-Scan-Signature: 58b614506802734014829a093beb6879 Cc: Subject: [XCON] RE: More comments on draft-ietf-xcon-framework-07.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: , Content-Type: multipart/mixed; boundary="===============0789316406==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0789316406== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78BD1.F0ABC82F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78BD1.F0ABC82F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 [Chris Boulton] In-line. =20 Hi Oscar, =20 Responses embedded below [MB]. =20 Thanks, Mary=20 -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]=20 Sent: Monday, April 30, 2007 2:57 AM To: Barnes, Mary (RICH2:AR00); xcon@ietf.org Cc: cboulton@ubiquitysoftware.com Subject: RE: More comments on draft-ietf-xcon-framework-07.txt Hi Mary,=20 =09=20 I have just a coupled of comments. =09=20 - I still think the replacement of the "common conference information" for "conference information data model" is important. Now, this concept is only defined in the framework and it can be very confusing for the readers. I don't think the substitution of this term will impact the whole text. In the framework you have this term only in 20 places, mainly in the 'terminology' and the 'centralized conferencing data model' section.=20 [MB] I do understand how the term "common" has lost its original context since we no longer have the templates, thus there's only one set of information. But, a global replacement won't work quite right, at least in terms of the basic definition, where the "common conference information" is defined as:=20 " The common conference information is the data type (i.e., the XML schema) for a conference object".=20=20 How about we just drop the phrase "common" and refer to it as "Conference Information"? [/MB] =09=20 [Chris Boulton] I'm OK with that. =09=20 =09=09=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_01C78BD1.F0ABC82F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

 

 

[Chris Boulton] In-line.

 

Hi Oscar,

 

Responses embedded below [MB].

 

Thanks,

Mary

-----Original Message-----
From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]
Sent: Mo= nday, April 30, 2007 2:57 AM
To: Barnes, Mary (RICH2:AR00= ); xcon@ietf.org
Cc: cboulton@ubiquitysoftwar= e.com
Subject: RE: More comments on draft-ietf-xcon-framework-07.txt

= Hi Mary,

 

= I have just a coupled of comments.

 

= - I still think the replacement of the "common conference information" for "conference information data model" is important. Now, this concept is only defined in the framework and it can be very confusing for t= he readers. I don't think the substitution of this term will impact the whole text. In the framework you have this term only in 20 places, mainly in the = 'terminology' and the 'centralized conferencing data model' section. =

[MB] I do understand how the term "common" has lost its original context since we no longer have the templates, thus there's only one set of information. But, a global replacement won't work quite right, at least in terms of the basic definition, where the "common confere= nce information" is defined as:

   " The common
      conference information is the data type (i.e= ., the XML schema) for
      a conference object". 

How about we just drop the phrase "common" and refer to it as "Conference Information"?

[/MB]

 

[Chris Boulton] I’m OK with that.

 

 



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_01C78BD1.F0ABC82F-- --===============0789316406== 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 --===============0789316406==-- From xcon-bounces@ietf.org Tue May 01 05:56:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hip5Y-0003yt-V5; Tue, 01 May 2007 05:56:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hip5X-0003yo-JQ for xcon@ietf.org; Tue, 01 May 2007 05:56:03 -0400 Received: from webmail.unina.it ([192.132.34.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hip5V-0004iz-Rx for xcon@ietf.org; Tue, 01 May 2007 05:56:03 -0400 Received: from webmail.unina.it (localhost [127.0.0.1]) by webmail.unina.it (8.12.11/8.12.11) with ESMTP id l41A2ugv023657; Tue, 1 May 2007 12:02:56 +0200 Received: (from nobody@localhost) by webmail.unina.it (8.12.11/8.12.11/Submit) id l41A2qdN023653; Tue, 1 May 2007 12:02:52 +0200 X-Authentication-Warning: webmail.unina.it: nobody set sender to spromano@unina.it using -f Received: from 217.201.143.227 ([217.201.143.227]) by webmail.unina.it (IMP) with HTTP for ; Tue, 1 May 2007 12:02:52 +0200 Message-ID: <1178013772.4637104c129e0@webmail.unina.it> Date: Tue, 1 May 2007 12:02:52 +0200 From: Simon Pietro Romano To: Mary Barnes Subject: RE: [XCON] Removing Policies from the framework document (and data model) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 217.201.143.227 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by webmail.unina.it id l41A2ugv023657 X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: Gonzalo Camarillo , 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: , Errors-To: xcon-bounces@ietf.org Just my two cents: imho we keep on wasting time on deciding "how to do wh= at", rather than focusing on "doing something". Policies and framework are ort= hogoal issues and, as such, they might be dealt with in parallel, and in a very = short time. I would invite all of you to think of the fact that the IETF should embrace a more light-weight approach to standards; the risk is that we en= d up in 10 years with a "perfect yet useless" (=E0 la ISO/OSI) protocol suite = for conferencing. To be proactive, I personally voulonteer in helping you with the work on = both the policy framework and the conference control protocol. With respect to policies, in particular, here at University of Napoli we have already set= up a basic XACML scenario which provides role-based access control to conferen= ce state information. We would be happy to go on with such work and to share= ideas with others in the group. Cheers,=20 Simon --=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ Scrive Mary Barnes : > More comments embedded below [MB]. >=20 > Mary >=20 >=20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Monday, April 30, 2007 12:00 PM > To: Barnes, Mary (RICH2:AR00) > Cc: xcon@ietf.org > Subject: Re: [XCON] Removing Policies from the framework document (and > data model) >=20 >=20 > Hi Mary, >=20 > > But, I still think we need to talk about policies in the context of > the > > framework (and in particular the read/write and how the child may or > may > > not also inherit policy properties from the parent). I think there > are > > implied requirements on the policy solution in the framework and I > don't > > want to lose the context of those. And, given the other thread > > proposing that the framework is informational, there would be nothing > > normative in this text. >=20 > sure, we can talk about that in the framework... but if we do that, I=20 > would suggest delaying the publication of the framework until we have a= =20 > clear idea on how policies will be specified. Talking about read/write=20 > and inheritance without knowing how policies are going to be implemente= d >=20 > seems a little risky to me. >=20 > [MB] I do not think we need to delay the framework. I don't think that > the idea of the child inheriting policy is so much a policy issue as it > is a system implementation issue. The inheritance concept was a basic > approach that we agreed long ago - the mechanisms to achieve that aren'= t > specified, but the idea is an important concept for describing how one > might design a conferencing system to support these various protocols. > The whole idea of the framework is to provide a context for describing > the protocols. I honestly think the text remains at an abstract enough > level that it's not going to limit an implementation, but rather guide > it. I think it would be really good if this group could agree that the= y > agree on these basic concepts before moving forward, but it really > matters not to me if we want to keep the framework within the WG until > all the protocol work is done. But, I didn't think that was the > direction the chairs intended us to go. =20 >=20 > I'm actually very happy to start talking about how we > can very easily implement policies based on XACML. And, I feel quite > comfortable in saying that the high level concepts in the framework > don't seem to cause any problems if that is selected.=20 > > [/MB] >=20 > > And, it should be clear that the policy mechanism is not defined in > this > > document and will be defined in another document, either as part of > the > > protocol document or a separate document. For the record, I am > opposed > > to this WG deciding at this time to work on a separate policy > document. > > I think the work plan of completing the data model and then working > out > > the details of the Conference Control Protocol should be worked, as I > > think the policy may be dependent upon the protocol choice.=20 >=20 > I am afraid I do not fully understand the work plan you propose in the=20 > paragraph above. Could you please clarify it for me? > [MB] My concern is that the group will rathole if we decide to go off > and define a policy control framework for the data model before we agre= e > the protocol for the conference control based on that data model. I > think once the group can agree a conference control protocol, the polic= y > approach might well be a straightforward choice of selecting something > that's already been developed.=20 > [/MB] >=20 >=20 > > The text I need to remove from the framework would be around policy > > information being an integral part of the data model. I think the > > general consensus seems to be that they are not. Folks, please speak > up > > now if you disagree with this point. >=20 > I believe we have consensus on working on the policy issues in a=20 > different Internet Draft. However, such an internet draft may very well= =20 > define policy elements that are an extension of the data model. In that= =20 > case, policies would indeed be part of the data model (they would=20 > actually be an extension of the data model). > [MB] I think we had consensus to not work on policy in the data model > and to not work on policy in the framework. However, my point above, I > think it's pre-mature for this group to start working a policy model. > Per the point above, I understood the work plan for this working group > to be to work on the protocol once we completed the data model. > [/MB] >=20 > If by "integral part" you mean that they are defined as part of the dat= a >=20 > model and not as an extension, then I agree with your statement. > [MB] Yes, on this one point, we agree. [/MB] >=20 > > I'll proposed the detailed text changes in a separate email in case > > folks what to debate this general topic further. And, it would be goo= d > > for some other voices to chime in with opinions.=20 >=20 > Yes, it would be great to hear different opinions. >=20 > Cheers, >=20 > Gonzalo >=20 > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon >=20 ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Sun May 06 07:10:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkedU-0000BI-PA; Sun, 06 May 2007 07:10:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HkedT-0000Ao-1d; Sun, 06 May 2007 07:10:39 -0400 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HkedR-0006m3-CQ; Sun, 06 May 2007 07:10:39 -0400 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JHM006ZD9QNCI@lhrga01-in.huawei.com>; Sun, 06 May 2007 12:11:12 +0100 (BST) Received: from jys3105093470ty ([121.34.104.160]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JHM0009F9QE9U@lhrga01-in.huawei.com>; Sun, 06 May 2007 12:11:11 +0100 (BST) Date: Sun, 06 May 2007 19:11:22 +0800 From: Linyi Tian To: sipping@ietf.org Message-id: <001c01c78fcf$4bf81420$0564a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_vnFNuQHabGBef5GosAV4bw)" Thread-index: AceMKho7gDJKxGrhRxy8GqhupxIcSgDpI4Ag X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: xcon@ietf.org Subject: [XCON] FW: I-D ACTION:draft-linyi-sipping-invite-with-conf-info-01.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 This is a multi-part message in MIME format. --Boundary_(ID_vnFNuQHabGBef5GosAV4bw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Dear all Based on comments I received these days, I have updated the draft to 01 version with following changes: 1. Revise the requirements and reasons why we need this mechanism to better reflect the intention 2. Give a restriction that the conference info in initial INVITE request and outgoing INVITE requests SHOULD be same to avoid the contradiction with Conference Event Package mechanism. 3. Detail the examples Please feel free to comment and give us feedback! Thank you in advance! Best Regards, Linyi -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, May 02, 2007 3:50 AM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-linyi-sipping-invite-with-conf-info-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Session Initiation Protocol (SIP) INVITE with Conference Info Author(s) : L. Tian, Q. Sun Filename : draft-linyi-sipping-invite-with-conf-info-01.txt Pages : 25 Date : 2007-5-1 This specification defines a mechanism that allows a UAC to provide a conference server with the initial conference information and policy using an INVITE-contained conference info. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-linyi-sipping-invite-with-conf-info-01.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-linyi-sipping-invite-with-conf-info-01.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-linyi-sipping-invite-with-conf-info-01.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. --Boundary_(ID_vnFNuQHabGBef5GosAV4bw) Content-type: Message/External-body; name=ATT00097.dat Content-transfer-encoding: 7bit Content-disposition: attachment; filename=ATT00097.dat Content-Type: text/plain Content-ID: <2007-5-1143357.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-linyi-sipping-invite-with-conf-info-01.txt --Boundary_(ID_vnFNuQHabGBef5GosAV4bw) Content-type: Message/External-body; name=draft-linyi-sipping-invite-with-conf-info-01.txt Content-transfer-encoding: 7bit Content-disposition: attachment; filename=draft-linyi-sipping-invite-with-conf-info-01.txt Content-Type: text/plain Content-ID: <2007-5-1143357.I-D@ietf.org> --Boundary_(ID_vnFNuQHabGBef5GosAV4bw) Content-type: text/plain; name=ATT00100.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ATT00100.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --Boundary_(ID_vnFNuQHabGBef5GosAV4bw) 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 --Boundary_(ID_vnFNuQHabGBef5GosAV4bw)-- From xcon-bounces@ietf.org Mon May 07 15:59:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl9MZ-0001s7-Re; Mon, 07 May 2007 15:59:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl9MZ-0001s2-3u for xcon@ietf.org; Mon, 07 May 2007 15:59:15 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl9MY-0006nm-QW for xcon@ietf.org; Mon, 07 May 2007 15:59:15 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l47JxBA12387; Mon, 7 May 2007 19:59:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] RE: Comments on draft-ietf-xcon-framework-07.txt Date: Mon, 7 May 2007 14:59:11 -0500 Message-ID: In-Reply-To: <4636A2CC.8080802@sipstation.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] RE: Comments on draft-ietf-xcon-framework-07.txt Thread-Index: AceLlqM9Y53p0KeiRMC5k/mZaF0e6wFSjjXQ From: "Mary Barnes" To: "Alan Johnston" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Gonzalo Camarillo , 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: , Errors-To: xcon-bounces@ietf.org Hi WG, There was a question embedded in this email from Alan to the WG with regards to whether folks think they can implement the protocols being familiar with the Framework, thus making it okay to make the framework informational at this point and there's been zero responses as far as I can tell. I personally feel the framework is necessary to understand the context of all the protcols and for baseline terminology (I can see great difficulties in spreading the terminology and concepts across multiple documents). But, I would be okay with it being changed to Informational IF we can get a work item chartered to provide detailed flows that we progress as a BCP.=20 Mary -----Original Message----- From: Alan Johnston [mailto:alan@sipstation.com]=20 Sent: Monday, April 30, 2007 9:16 PM To: Barnes, Mary (RICH2:AR00) Cc: Gonzalo Camarillo; xcon@ietf.org Subject: Re: [XCON] RE: Comments on draft-ietf-xcon-framework-07.txt Our working group charter lists the framework as a PS, not=20 informational, and we did discuss it in Prague and agree to do that. I do recall that in the SIPPING conferencing work, we ended up making=20 the conference framework document informational and the cc-conferencing=20 a BCP. We could do something similar as Mary points out below. A question - does the working group believe that implementors can just=20 read BFCP, the common data model, the event package extension, and the=20 future conference control protocol documents and be able to implement=20 without reading the framework? If so, that suggests the framework can=20 be informational. If not, if there is significant overall detail in the=20 framework, then we should not make it informational for the sake of=20 implementors. Thanks, Alan Mary Barnes wrote: > I don't think we need a BCP right now for the flows, but once we decide > the Conference Control Protocol, I think a BCP with flows (e.g., taking > some of the examples in the framework down to another level of detail) > would be very useful.=20 > > Mary > > > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Monday, April 30, 2007 11:42 AM > To: Barnes, Mary (RICH2:AR00) > Cc: xcon@ietf.org > Subject: Re: Comments on draft-ietf-xcon-framework-07.txt > > > Hi, > > sure, getting guidance from the chairs on the intended status would be > great. > > =20 >> I don't have any issue with changing this to informational, although, >> having the musts, shoulds all being in examples highlights perhaps the >> need to have a call flow BCP type document. >> =20 > > The protocol specs (e.g., SIP, BFCP) already specify the interactions=20 > between nodes in the context of those protocols. A BCP along the lines > you describe would be useful if the interactions between different=20 > protocols would be particularly complicated (e.g., which SIP message to=20 > send when a conference is terminated through the conference control=20 > protocol). However, I do not think the inter-protocol interactions we=20 > are dealing with in XCON are complicated enough to grant yet another=20 > specification. Or do you have a few scenarios in mind that may be=20 > difficult to understand for an implementer without a document with > examples? > > Cheers, > > Gonzalo > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon > > > =20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Mon May 07 16:33:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl9tT-00058u-4L; Mon, 07 May 2007 16:33:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl9tS-00058k-2F for xcon@ietf.org; Mon, 07 May 2007 16:33:14 -0400 Received: from smtp-out4.libero.it ([212.52.84.46]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl9tR-0001z5-Hk for xcon@ietf.org; Mon, 07 May 2007 16:33:14 -0400 Received: from localhost (172.31.0.52) by smtp-out4.libero.it (7.3.120) id 4611FF52021349D1; Mon, 7 May 2007 22:33:12 +0200 X-Scanned: with antispam and antivirus automated system at libero.it Received: from smtp-out3.libero.it ([172.31.0.39]) by localhost (asav-out11.libero.it [192.168.32.39]) (amavisd-new, port 10024) with ESMTP id p0r0d5YAzR3L; Mon, 7 May 2007 22:33:12 +0200 (CEST) Received: from [192.168.1.100] (151.63.84.141) by smtp-out3.libero.it (7.3.120) id 4611FDB60303EB9F; Mon, 7 May 2007 22:33:12 +0200 From: Lorenzo Miniero To: xcon@ietf.org Subject: Re: [XCON] RE: Comments on draft-ietf-xcon-framework-07.txt Date: Mon, 7 May 2007 22:33:05 +0200 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200705072233.05675.lorenzo.miniero@unina.it> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: Alan Johnston , Gonzalo Camarillo X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lorenzo.miniero@unina.it List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Mary, I agree with you upon the importance of the framework document, which shoul= d=20 keep on being more than informational. It is my opinion that it still deals= =20 with relevant issues that the data model draft doesn't cover, and justly so. Lorenzo On Monday 07 May 2007 21:59:11 Mary Barnes wrote: > Hi WG, > > There was a question embedded in this email from Alan to the WG with > regards to whether folks think they can implement the protocols being > familiar with the Framework, thus making it okay to make the framework > informational at this point and there's been zero responses as far as I > can tell. > > I personally feel the framework is necessary to understand the context > of all the protcols and for baseline terminology (I can see great > difficulties in spreading the terminology and concepts across multiple > documents). But, I would be okay with it being changed to Informational > IF we can get a work item chartered to provide detailed flows that we > progress as a BCP. > > Mary > > > -----Original Message----- > From: Alan Johnston [mailto:alan@sipstation.com] > Sent: Monday, April 30, 2007 9:16 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Gonzalo Camarillo; xcon@ietf.org > Subject: Re: [XCON] RE: Comments on draft-ietf-xcon-framework-07.txt > > > Our working group charter lists the framework as a PS, not > informational, and we did discuss it in Prague and agree to do that. > > I do recall that in the SIPPING conferencing work, we ended up making > the conference framework document informational and the cc-conferencing > a BCP. We could do something similar as Mary points out below. > > A question - does the working group believe that implementors can just > read BFCP, the common data model, the event package extension, and the > future conference control protocol documents and be able to implement > without reading the framework? If so, that suggests the framework can > be informational. If not, if there is significant overall detail in the > framework, then we should not make it informational for the sake of > implementors. > > Thanks, > Alan > > Mary Barnes wrote: > > I don't think we need a BCP right now for the flows, but once we > > decide > > > the Conference Control Protocol, I think a BCP with flows (e.g., > > taking > > > some of the examples in the framework down to another level of detail) > > would be very useful. > > > > Mary > > > > > > -----Original Message----- > > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > > Sent: Monday, April 30, 2007 11:42 AM > > To: Barnes, Mary (RICH2:AR00) > > Cc: xcon@ietf.org > > Subject: Re: Comments on draft-ietf-xcon-framework-07.txt > > > > > > Hi, > > > > sure, getting guidance from the chairs on the intended status would be > > > > great. > > > >> I don't have any issue with changing this to informational, although, > >> having the musts, shoulds all being in examples highlights perhaps > > the > > >> need to have a call flow BCP type document. > > > > The protocol specs (e.g., SIP, BFCP) already specify the interactions > > between nodes in the context of those protocols. A BCP along the lines > > > > you describe would be useful if the interactions between different > > protocols would be particularly complicated (e.g., which SIP message > > to > > > send when a conference is terminated through the conference control > > protocol). However, I do not think the inter-protocol interactions we > > are dealing with in XCON are complicated enough to grant yet another > > specification. Or do you have a few scenarios in mind that may be > > difficult to understand for an implementer without a document with > > examples? > > > > Cheers, > > > > Gonzalo > > > > _______________________________________________ > > XCON mailing list > > XCON@ietf.org > > https://www1.ietf.org/mailman/listinfo/xcon > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www1.ietf.org/mailman/listinfo/xcon =2D-=20 Lorenzo Miniero, Junior Researcher Dipartimento di Informatica e Sistemistica Universit=E0 degli Studi di Napoli "Federico II" Via Claudio 21 -- 80125 Napoli (Italy) Phone: +390817683821 - Fax: +390817683816 Email: lorenzo.miniero@unina.it _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue May 08 03:03: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 1HlJiq-0001GH-Q9; Tue, 08 May 2007 03:02:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlJiq-0001DR-32 for xcon@ietf.org; Tue, 08 May 2007 03:02:56 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlJio-0001By-W6 for xcon@ietf.org; Tue, 08 May 2007 03:02:56 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8F406207F0; Tue, 8 May 2007 09:02:53 +0200 (CEST) X-AuditID: c1b4fb3c-a84eabb0000073d5-c9-4640209d3534 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 73079207F1; Tue, 8 May 2007 09:02:53 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 09:02:53 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 09:02:52 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id ABD102658; Tue, 8 May 2007 10:02:52 +0300 (EEST) Message-ID: <4640209B.9090707@ericsson.com> Date: Tue, 08 May 2007 10:02:51 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: lorenzo.miniero@unina.it Subject: Re: [XCON] RE: Comments on draft-ietf-xcon-framework-07.txt References: <200705072233.05675.lorenzo.miniero@unina.it> In-Reply-To: <200705072233.05675.lorenzo.miniero@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 May 2007 07:02:53.0033 (UTC) FILETIME=[E5A7D590:01C7913E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: Alan Johnston , 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: , Errors-To: xcon-bounces@ietf.org Folks, note that we are not discussing useless vs. useful. We are discussing Informational vs. Standards-track. There are a lot of documents that are very useful but still are Informational and not Standards-track. Regarding generating more documents, before starting producing tons of tutorial material, call flows, etc., we need to understand what it is that is not clear for implementers. I have asked a few implementers and all of them told me that they found it very useful to know the architecture the XCON WG has in mind (i.e., Figure 1 of the framework and its explanation). Additionally, all of them told me that having a 62-page document to explain such architecture was way too much and that they did not intend to finish reading it (coming back to the previous discussion, implementers read specs because they are useful, not because they are Standards-track or because we as a WG tell them to read them). My suggestion would be to have the WG focus on finishing our chartered items (e.g., the policy part of the data model and the conference control protocol) instead of focusing of producing more and more examples, tutorials, call flows, etc. Once the protocol work is done, if we think more examples are needed and we have some energy left (so far the energy level we have shown is not that high), we can work on them at that point. Cheers, Gonzalo Lorenzo Miniero wrote: > Hi Mary, > > I agree with you upon the importance of the framework document, which should > keep on being more than informational. It is my opinion that it still deals > with relevant issues that the data model draft doesn't cover, and justly so. > > Lorenzo > > > On Monday 07 May 2007 21:59:11 Mary Barnes wrote: >> Hi WG, >> >> There was a question embedded in this email from Alan to the WG with >> regards to whether folks think they can implement the protocols being >> familiar with the Framework, thus making it okay to make the framework >> informational at this point and there's been zero responses as far as I >> can tell. >> >> I personally feel the framework is necessary to understand the context >> of all the protcols and for baseline terminology (I can see great >> difficulties in spreading the terminology and concepts across multiple >> documents). But, I would be okay with it being changed to Informational >> IF we can get a work item chartered to provide detailed flows that we >> progress as a BCP. >> >> Mary >> >> >> -----Original Message----- >> From: Alan Johnston [mailto:alan@sipstation.com] >> Sent: Monday, April 30, 2007 9:16 PM >> To: Barnes, Mary (RICH2:AR00) >> Cc: Gonzalo Camarillo; xcon@ietf.org >> Subject: Re: [XCON] RE: Comments on draft-ietf-xcon-framework-07.txt >> >> >> Our working group charter lists the framework as a PS, not >> informational, and we did discuss it in Prague and agree to do that. >> >> I do recall that in the SIPPING conferencing work, we ended up making >> the conference framework document informational and the cc-conferencing >> a BCP. We could do something similar as Mary points out below. >> >> A question - does the working group believe that implementors can just >> read BFCP, the common data model, the event package extension, and the >> future conference control protocol documents and be able to implement >> without reading the framework? If so, that suggests the framework can >> be informational. If not, if there is significant overall detail in the >> framework, then we should not make it informational for the sake of >> implementors. >> >> Thanks, >> Alan >> >> Mary Barnes wrote: >>> I don't think we need a BCP right now for the flows, but once we >> decide >> >>> the Conference Control Protocol, I think a BCP with flows (e.g., >> taking >> >>> some of the examples in the framework down to another level of detail) >>> would be very useful. >>> >>> Mary >>> >>> >>> -----Original Message----- >>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>> Sent: Monday, April 30, 2007 11:42 AM >>> To: Barnes, Mary (RICH2:AR00) >>> Cc: xcon@ietf.org >>> Subject: Re: Comments on draft-ietf-xcon-framework-07.txt >>> >>> >>> Hi, >>> >>> sure, getting guidance from the chairs on the intended status would be >>> >>> great. >>> >>>> I don't have any issue with changing this to informational, although, >>>> having the musts, shoulds all being in examples highlights perhaps >> the >> >>>> need to have a call flow BCP type document. >>> The protocol specs (e.g., SIP, BFCP) already specify the interactions >>> between nodes in the context of those protocols. A BCP along the lines >>> >>> you describe would be useful if the interactions between different >>> protocols would be particularly complicated (e.g., which SIP message >> to >> >>> send when a conference is terminated through the conference control >>> protocol). However, I do not think the inter-protocol interactions we >>> are dealing with in XCON are complicated enough to grant yet another >>> specification. Or do you have a few scenarios in mind that may be >>> difficult to understand for an implementer without a document with >>> examples? >>> >>> Cheers, >>> >>> Gonzalo >>> >>> _______________________________________________ >>> XCON mailing list >>> XCON@ietf.org >>> https://www1.ietf.org/mailman/listinfo/xcon >> _______________________________________________ >> XCON mailing list >> XCON@ietf.org >> https://www1.ietf.org/mailman/listinfo/xcon > > > _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Tue May 08 16:02: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 1HlVsn-0005Jx-FV; Tue, 08 May 2007 16:02:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlVsl-0005Cj-T5 for xcon@ietf.org; Tue, 08 May 2007 16:01:59 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlVsj-0002v0-C1 for xcon@ietf.org; Tue, 08 May 2007 16:01:59 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l48K1rK25307; Tue, 8 May 2007 20:01:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] RE: Comments on draft-ietf-xcon-framework-07.txt Date: Tue, 8 May 2007 15:01:05 -0500 Message-ID: In-Reply-To: <4640209B.9090707@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] RE: Comments on draft-ietf-xcon-framework-07.txt Thread-Index: AceRPu4ZBQh3y/pRSSed3mFJkCqrPAAaoHDA From: "Mary Barnes" To: "Gonzalo Camarillo" , X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: Alan Johnston , 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: , Errors-To: xcon-bounces@ietf.org Just a few more comments embedded below for clarification. What I'm taking from this thread is that most folks are okay with changing the delivery of the framework from a standards track to an informational document. So, my plan is to reflect that in the -08 version of the framework.=20 Mary -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Sent: Tuesday, May 08, 2007 2:03 AM To: lorenzo.miniero@unina.it Cc: xcon@ietf.org; Barnes, Mary (RICH2:AR00); Alan Johnston Subject: Re: [XCON] RE: Comments on draft-ietf-xcon-framework-07.txt Folks, note that we are not discussing useless vs. useful. We are discussing=20 Informational vs. Standards-track. There are a lot of documents that are very useful but still are Informational and not Standards-track. Regarding generating more documents, before starting producing tons of=20 tutorial material, call flows, etc., we need to understand what it is=20 that is not clear for implementers. [MB] Just for clarification, I'm not suggesting that we start working on the flows now, but I think if we consider the flows in the framework to be non-normative, then I think a separate document is a must and I'm only asking that we put it in the workplan and not that we agree to work on it now.=20 [/MB] I have asked a few implementers and all of them told me that they found=20 it very useful to know the architecture the XCON WG has in mind (i.e.,=20 Figure 1 of the framework and its explanation). Additionally, all of=20 them told me that having a 62-page document to explain such architecture was way too much and that they did not intend to finish reading it=20 (coming back to the previous discussion, implementers read specs because they are useful, not because they are Standards-track or because we as a WG tell them to read them). [MB] Another point for clarifiction. The example scenarios start at page 26 and end on page 48, so that's 20+ pages of detailed examples, over half of which is diagrams for folks that are more visual learners. 6 pages (10% of the document) are change summaries that won't be in the final RFC. The guts of what one needs to understand with regards to the framework is covered from pages 10-26 (16 pages, 6 of which include mostly full page diagrams), so I don't think around 10 pages of text is too much to read for most implementers. =20 [/MB] My suggestion would be to have the WG focus on finishing our chartered=20 items (e.g., the policy part of the data model and the conference=20 control protocol) instead of focusing of producing more and more=20 examples, tutorials, call flows, etc. Once the protocol work is done, if we think more examples are needed and we have some energy left (so far=20 the energy level we have shown is not that high), we can work on them at that point. [MB] I think we're all in agreement on the importance of moving forward. >From the charter the next item to complete is the framework and then there are two charter items that are believe are now subsumed into the current data model document. Then, we have the conference control protocol, which I think is what most of us believe we need to be focusing on at this point. I think the policy can fall very naturally from this work as should detailed data flows (again for the folks that are visual learners). [/MB] Cheers, Gonzalo Lorenzo Miniero wrote: > Hi Mary, >=20 > I agree with you upon the importance of the framework document, which should=20 > keep on being more than informational. It is my opinion that it still deals=20 > with relevant issues that the data model draft doesn't cover, and justly so. >=20 > Lorenzo >=20 >=20 > On Monday 07 May 2007 21:59:11 Mary Barnes wrote: >> Hi WG, >> >> There was a question embedded in this email from Alan to the WG with >> regards to whether folks think they can implement the protocols being >> familiar with the Framework, thus making it okay to make the framework >> informational at this point and there's been zero responses as far as I >> can tell. >> >> I personally feel the framework is necessary to understand the context >> of all the protcols and for baseline terminology (I can see great >> difficulties in spreading the terminology and concepts across multiple >> documents). But, I would be okay with it being changed to Informational >> IF we can get a work item chartered to provide detailed flows that we >> progress as a BCP. >> >> Mary >> >> >> -----Original Message----- >> From: Alan Johnston [mailto:alan@sipstation.com] >> Sent: Monday, April 30, 2007 9:16 PM >> To: Barnes, Mary (RICH2:AR00) >> Cc: Gonzalo Camarillo; xcon@ietf.org >> Subject: Re: [XCON] RE: Comments on draft-ietf-xcon-framework-07.txt >> >> >> Our working group charter lists the framework as a PS, not >> informational, and we did discuss it in Prague and agree to do that. >> >> I do recall that in the SIPPING conferencing work, we ended up making >> the conference framework document informational and the cc-conferencing >> a BCP. We could do something similar as Mary points out below. >> >> A question - does the working group believe that implementors can just >> read BFCP, the common data model, the event package extension, and the >> future conference control protocol documents and be able to implement >> without reading the framework? If so, that suggests the framework can >> be informational. If not, if there is significant overall detail in the >> framework, then we should not make it informational for the sake of >> implementors. >> >> Thanks, >> Alan >> >> Mary Barnes wrote: >>> I don't think we need a BCP right now for the flows, but once we >> decide >> >>> the Conference Control Protocol, I think a BCP with flows (e.g., >> taking >> >>> some of the examples in the framework down to another level of detail) >>> would be very useful. >>> >>> Mary >>> >>> >>> -----Original Message----- >>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>> Sent: Monday, April 30, 2007 11:42 AM >>> To: Barnes, Mary (RICH2:AR00) >>> Cc: xcon@ietf.org >>> Subject: Re: Comments on draft-ietf-xcon-framework-07.txt >>> >>> >>> Hi, >>> >>> sure, getting guidance from the chairs on the intended status would be >>> >>> great. >>> >>>> I don't have any issue with changing this to informational, although, >>>> having the musts, shoulds all being in examples highlights perhaps >> the >> >>>> need to have a call flow BCP type document. >>> The protocol specs (e.g., SIP, BFCP) already specify the interactions >>> between nodes in the context of those protocols. A BCP along the lines >>> >>> you describe would be useful if the interactions between different >>> protocols would be particularly complicated (e.g., which SIP message >> to >> >>> send when a conference is terminated through the conference control >>> protocol). However, I do not think the inter-protocol interactions we >>> are dealing with in XCON are complicated enough to grant yet another >>> specification. Or do you have a few scenarios in mind that may be >>> difficult to understand for an implementer without a document with >>> examples? >>> >>> Cheers, >>> >>> Gonzalo >>> >>> _______________________________________________ >>> XCON mailing list >>> XCON@ietf.org >>> https://www1.ietf.org/mailman/listinfo/xcon >> _______________________________________________ >> XCON mailing list >> XCON@ietf.org >> https://www1.ietf.org/mailman/listinfo/xcon >=20 >=20 >=20 _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri May 11 11:51: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 1HmXOg-0003R9-L1; Fri, 11 May 2007 11:51:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmXOg-0003R4-11 for xcon@ietf.org; Fri, 11 May 2007 11:51:10 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmXOe-0007Ss-Pt for xcon@ietf.org; Fri, 11 May 2007 11:51:10 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JHV00LQLVP9O4@usaga01-in.huawei.com> for xcon@ietf.org; Fri, 11 May 2007 08:43:57 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JHV0092SVP8S2@usaga01-in.huawei.com> for xcon@ietf.org; Fri, 11 May 2007 08:43:57 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [219.134.35.239]) by szxmc04-in.huawei.com (mshttpd); Fri, 11 May 2007 23:43:54 +0800 Date: Fri, 11 May 2007 23:43:54 +0800 From: RahulSrivastava 71616 To: xcon@ietf.org Message-id: <4a9821c4a9c59f.4a9c59f4a9821c@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [XCON] Query 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 One question to this group. Each media server has different ways for storing files for annoucement,voice mails etc...even for same protocols different vendors might support different ways...is this group going to standardize this or at least publish some guidelines about it? Regards, Rahul ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri May 11 13:10:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmYdG-0001Su-Du; Fri, 11 May 2007 13:10:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmYdF-0001Sl-O4 for xcon@ietf.org; Fri, 11 May 2007 13:10:17 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmYdE-00077r-43 for xcon@ietf.org; Fri, 11 May 2007 13:10:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] Query Date: Fri, 11 May 2007 20:10:49 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C048EAABA@IsrExch01.israel.polycom.com> In-Reply-To: <4a9821c4a9c59f.4a9c59f4a9821c@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Query Thread-Index: AceT5E4X9csq9I5LTJenc2y6XbOBDAACteNg From: "Even, Roni" To: "RahulSrivastava 71616" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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: , Errors-To: xcon-bounces@ietf.org Rahul, This may be more in the MEDIACTRL WG charter http://www.ietf.org/html.charters/mediactrl-charter.html Roni Even > -----Original Message----- > From: RahulSrivastava 71616 [mailto:rahuls@huawei.com] > Sent: Friday, May 11, 2007 6:44 PM > To: xcon@ietf.org > Subject: [XCON] Query >=20 > One question to this group. > Each media server has different ways for storing files for > annoucement,voice mails etc...even for same protocols different vendors > might support different ways...is this group going to standardize this or > at least publish some guidelines about it? >=20 >=20 > Regards, > Rahul >=20 > ************************************************************************ ** > **************** > This email and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, reproduction, > or dissemination) by persons other than the intended recipient(s) is > prohibited. If you receive this e-mail in error, please notify the sender > by phone or email immediately and delete it! >=20 > ************************************************************************ ** > *************** >=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 Mon May 14 10:22:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnbRy-0006qg-Lx; Mon, 14 May 2007 10:22:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnbRx-0006qb-Q6 for xcon@ietf.org; Mon, 14 May 2007 10:22:57 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnbRv-00059q-Pq for xcon@ietf.org; Mon, 14 May 2007 10:22:57 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3A5E4203B2; Mon, 14 May 2007 16:22:55 +0200 (CEST) X-AuditID: c1b4fb3e-ae9ecbb0000061ca-1d-464870bff2f9 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0F00921189; Mon, 14 May 2007 16:22:55 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 16:22:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 May 2007 16:22:02 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More comments on draft-ietf-xcon-framework-07.txt Thread-Index: AceHPwmeREeU/PqhQJ2OLBJG23H9ywALOemwAOICnhAACayuQALF/Wiw References: From: "Oscar Novo \(JO/LMF\)" To: "Mary Barnes" , X-OriginalArrivalTime: 14 May 2007 14:22:54.0965 (UTC) FILETIME=[5CE97250:01C79633] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Cc: cboulton@ubiquitysoftware.com Subject: [XCON] RE: More comments on draft-ietf-xcon-framework-07.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: , Content-Type: multipart/mixed; boundary="===============0537752603==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0537752603== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79633.3D828B54" This is a multi-part message in MIME format. ------_=_NextPart_001_01C79633.3D828B54 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mary, =20 Comments inline as [ON] =20 Regards, =20 Oscar ________________________________ From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: 30. huhtikuuta 2007 14:37 To: Oscar Novo (JO/LMF); xcon@ietf.org Cc: cboulton@ubiquitysoftware.com Subject: RE: More comments on draft-ietf-xcon-framework-07.txt Hi Oscar, =20 Responses embedded below [MB]. =20 Thanks, Mary=20 =09 -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]=20 Sent: Monday, April 30, 2007 2:57 AM To: Barnes, Mary (RICH2:AR00); xcon@ietf.org Cc: cboulton@ubiquitysoftware.com Subject: RE: More comments on draft-ietf-xcon-framework-07.txt =09 =09 Hi Mary,=20 =20 I have just a coupled of comments. =20 - I still think the replacement of the "common conference information" for "conference information data model" is important. Now, this concept is only defined in the framework and it can be very confusing for the readers. I don't think the substitution of this term will impact the whole text. In the framework you have this term only in 20 places, mainly in the 'terminology' and the 'centralized conferencing data model' section.=20 [MB] I do understand how the term "common" has lost its original context since we no longer have the templates, thus there's only one set of information. But, a global replacement won't work quite right, at least in terms of the basic definition, where the "common conference information" is defined as:=20 " The common conference information is the data type (i.e., the XML schema) for a conference object". =20 How about we just drop the phrase "common" and refer to it as "Conference Information"? [/MB]=20 =20 [ON] OK, for me it's fine if we change "Common Conference Information" for "Conference Information" =20 - Regarding section 5.1 there is some text not clear and very confuse, for instance:=20 "The data model defined in [17] would be the basis for conferencing systems supporting enhanced conferencing features.The additional information defined in [17] provides the details of the specific media mixing details, the associated client roles and the available floor controls".=20 The data model doesn't define any additional information. That was defined in the template document. That's why I said that section still have some concepts about the templates.=20 [MB] Okay, now I see your specific concern. Would it be clearer and less confusing if we just drop "additional" from that sentence? [/MB]=20 =20 [ON] Actually the problem is not only in that sentence although in all the section. I recommend you to re-write a bit more all section 5.1. In previous e-mails I sent you a text for section 5.1. You could use that text if you think is suitable for your draft. =20 ------_=_NextPart_001_01C79633.3D828B54 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Mary,
 
Comments inline as [ON]
 
 
Oscar

From: Mary Barnes=20 [mailto:mary.barnes@nortel.com]
Sent: 30. huhtikuuta 2007=20 14:37
To: Oscar Novo (JO/LMF); xcon@ietf.org
Cc:=20 cboulton@ubiquitysoftware.com
Subject: RE: More comments on=20 draft-ietf-xcon-framework-07.txt

Hi=20 Oscar,
 
Responses embedded below = [MB].
 
Thanks,
Regards,
Mary =
-----Original Message-----
From: = Oscar Novo=20 (JO/LMF) [mailto:oscar.novo@ericsson.com]
Sent: Monday, = April 30,=20 2007 2:57 AM
To: Barnes, Mary (RICH2:AR00);=20 xcon@ietf.org
Cc: = cboulton@ubiquitysoftware.com
Subject:=20 RE: More comments on = draft-ietf-xcon-framework-07.txt

Hi=20 Mary,
 
I=20 have just a coupled of comments.
 
- I still think the replacement of the "common conference = information"=20 for "conference information data model" is important. Now, this = concept is=20 only defined in the framework and it can be very confusing for the = readers. I=20 don't think the substitution of this term will impact the whole text. = In the=20 framework you have this term only in 20 places, mainly in the=20 'terminology' and the 'centralized conferencing data=20 model' section. 
[MB] I = do understand=20 how the term "common" has lost its original context since we no longer = have=20 the templates, thus there's only one set of information. But, a = global=20 replacement won't work quite right, at least in terms of the = basic=20 definition, where the "common conference information" is defined = as:=20
   = " The=20 common
      conference information is the = data=20 type (i.e., the XML schema) for
      a = conference=20 object". 
How about we = just drop the=20 phrase "common" and refer to it as "Conference=20 Information"?
[/MB] 
&nbs= p;
[ON] OK, for me it's fine if we change "Common Conference=20 Information" for "Conference=20 Information"
 
- Regarding section 5.1 there is some text not clear and = very=20 confuse, for instance:
"The data model defined in [17] would be the basis for = conferencing=20 systems supporting enhanced conferencing features.The additional information defined in [17] provides the details = of the specific=20 media mixing details, the associated client roles and the available = floor=20 controls".
The data model doesn't define any additional information. = That was=20 defined in the template document. That's why I said that = section still=20 have some concepts about the templates. 
[MB] Okay, = now I see your=20 specific concern.  Would it be clearer and less confusing if = we just=20 drop "additional" from that sentence? =20 [/MB] 
 
[ON] = Actually the=20 problem is not only in that sentence although in all the section. I = recommend=20 you to re-write a bit more all section 5.1. In previous e-mails I sent = you a=20 text for section 5.1. You could use that text if you think is suitable = for=20 your draft.
 
------_=_NextPart_001_01C79633.3D828B54-- --===============0537752603== 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 --===============0537752603==-- From xcon-bounces@ietf.org Mon May 14 12:14:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HndC2-0001MP-89; Mon, 14 May 2007 12:14:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HndC1-0001MJ-G1 for xcon@ietf.org; Mon, 14 May 2007 12:14:37 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HndC0-0002BR-QG for xcon@ietf.org; Mon, 14 May 2007 12:14:37 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4EGDuI02387; Mon, 14 May 2007 16:13:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 May 2007 11:13:36 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More comments on draft-ietf-xcon-framework-07.txt Thread-Index: AceHPwmeREeU/PqhQJ2OLBJG23H9ywALOemwAOICnhAACayuQALF/WiwAAHwkSA= From: "Mary Barnes" To: "Oscar Novo \(JO/LMF\)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 93ea548d5fde6eb89af31f1faab96344 Cc: cboulton@ubiquitysoftware.com Subject: [XCON] RE: More comments on draft-ietf-xcon-framework-07.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: , Content-Type: multipart/mixed; boundary="===============0092321679==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0092321679== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79642.D349965C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C79642.D349965C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One more comment below [MB2]. =20 =20 Mary=20 -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]=20 Sent: Monday, May 14, 2007 9:22 AM To: Barnes, Mary (RICH2:AR00); xcon@ietf.org Cc: cboulton@ubiquitysoftware.com Subject: RE: More comments on draft-ietf-xcon-framework-07.txt =09 =09 Mary, =20 Comments inline as [ON] =20 Regards, =20 Oscar =09 =09 ________________________________ From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: 30. huhtikuuta 2007 14:37 To: Oscar Novo (JO/LMF); xcon@ietf.org Cc: cboulton@ubiquitysoftware.com Subject: RE: More comments on draft-ietf-xcon-framework-07.txt =09 =09 Hi Oscar, =20 Responses embedded below [MB]. =20 Thanks, Mary=20 =09 -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]=20 Sent: Monday, April 30, 2007 2:57 AM To: Barnes, Mary (RICH2:AR00); xcon@ietf.org Cc: cboulton@ubiquitysoftware.com Subject: RE: More comments on draft-ietf-xcon-framework-07.txt =09 =09 Hi Mary,=20 =20 I have just a coupled of comments. =20 - I still think the replacement of the "common conference information" for "conference information data model" is important. Now, this concept is only defined in the framework and it can be very confusing for the readers. I don't think the substitution of this term will impact the whole text. In the framework you have this term only in 20 places, mainly in the 'terminology' and the 'centralized conferencing data model' section.=20 [MB] I do understand how the term "common" has lost its original context since we no longer have the templates, thus there's only one set of information. But, a global replacement won't work quite right, at least in terms of the basic definition, where the "common conference information" is defined as:=20 " The common conference information is the data type (i.e., the XML schema) for a conference object". =20 How about we just drop the phrase "common" and refer to it as "Conference Information"? [/MB]=20 =20 [ON] OK, for me it's fine if we change "Common Conference Information" for "Conference Information" =20 - Regarding section 5.1 there is some text not clear and very confuse, for instance:=20 "The data model defined in [17] would be the basis for conferencing systems supporting enhanced conferencing features.The additional information defined in [17] provides the details of the specific media mixing details, the associated client roles and the available floor controls".=20 The data model doesn't define any additional information. That was defined in the template document. That's why I said that section still have some concepts about the templates.=20 [MB] Okay, now I see your specific concern. Would it be clearer and less confusing if we just drop "additional" from that sentence? [/MB]=20 =20 [ON] Actually the problem is not only in that sentence although in all the section. I recommend you to re-write a bit more all section 5.1. In previous e-mails I sent you a text for section 5.1. You could use that text if you think is suitable for your draft.=20 =20 [MB2] But, I think that initial suggestion was missing the point that the model in the framework must support clients that just support only the data in the SIPPING event pkg and that don't support the data model define [17 - the XCON data model]. Those paragraphs are intended to provide the justification for defining additional data beyond that provided=20 by the SIPPING event package.=20 =20 I did make some other slight changes to that text here's the OLD/NEW of that 2nd paragraph in section 5.1: OLD: In order to support more complex media manipulations and enhanced conferencing features the common conference information contains additional data, beyond that defined in [10]. The data model defined in [17] would be the basis for conferencing systems supporting enhanced conferencing features. The additional information defined in [17] provides the details of the specific media mixing details, the associated client roles and the available floor controls. This information would allow authorized clients to manipulate the mixer's behavior via the focus, and the resultant distribution of the media to all or individual participants. By doing so, a client can change its own state and/or state of other participants in the conference. =20 =20 NEW: In order to support more complex media manipulations and enhanced conferencing features the conference information, as reflected by the=20 data model defined in [17], contains additional data beyond that defined in [10]. The information defined in [17]=20 provides specific media mixing details,=20 available floor controls and other data necessary to support enhanced=20 conferencing features. This information allows authorized clients to manipulate the mixer's behavior via the focus, with the resultant distribution of the media to all or individual participants. By doing so, a client can change its own state and/or state of other participants in the conference. =20 [/MB2] =20 =20 ------_=_NextPart_001_01C79642.D349965C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
One=20 more comment below [MB2]. 
 
Mary =
-----Original Message-----
From: = Oscar Novo=20 (JO/LMF) [mailto:oscar.novo@ericsson.com]
Sent: Monday, May = 14,=20 2007 9:22 AM
To: Barnes, Mary (RICH2:AR00);=20 xcon@ietf.org
Cc: = cboulton@ubiquitysoftware.com
Subject:=20 RE: More comments on = draft-ietf-xcon-framework-07.txt

Mary,
 
Comments inline as [ON]
 
Regards,
 
Oscar

From: Mary Barnes=20 [mailto:mary.barnes@nortel.com]
Sent: 30. huhtikuuta 2007=20 14:37
To: Oscar Novo (JO/LMF); xcon@ietf.org
Cc:=20 cboulton@ubiquitysoftware.com
Subject: RE: More comments on=20 draft-ietf-xcon-framework-07.txt

Hi=20 Oscar,
 
Responses embedded below = [MB].
 
Thanks,
Mary =
-----Original Message-----
From: = Oscar Novo=20 (JO/LMF) [mailto:oscar.novo@ericsson.com]
Sent: Monday, = April 30,=20 2007 2:57 AM
To: Barnes, Mary (RICH2:AR00);=20 xcon@ietf.org
Cc: = cboulton@ubiquitysoftware.com
Subject:=20 RE: More comments on = draft-ietf-xcon-framework-07.txt

Hi=20 Mary,
 
I=20 have just a coupled of comments.
 
- I still think the replacement of = the "common=20 conference information" for "conference information data model" is=20 important. Now, this concept is only defined in the framework and it = can be=20 very confusing for the readers. I don't think the substitution of = this term=20 will impact the whole text. In the framework you have this term only = in 20=20 places, mainly in the 'terminology' and the 'centralized = conferencing=20 data model' section. 
[MB] I do=20 understand how the term "common" has lost its original context since = we no=20 longer have the templates, thus there's only one set of information. = But, a global replacement won't work quite right, at least = in=20 terms of the basic definition, where the "common conference=20 information" is defined as:
   " The=20 common
      conference information is = the data=20 type (i.e., the XML schema) for
      a=20 conference object". 
How about = we just drop=20 the phrase "common" and refer to it as "Conference=20 Information"?
[/MB] 
&nbs= p;
[ON] OK, for me it's fine if we change "Common Conference = Information" for "Conference=20 Information"
 
- Regarding section 5.1 there is some text not clear = and very=20 confuse, for instance:
"The data model defined in [17] would be the basis = for=20 conferencing systems supporting enhanced conferencing = features.The additional information defined in = [17] = provides the details of=20 the specific media mixing details, the associated client roles and = the=20 available floor controls".
The data model doesn't define any additional = information. That=20 was defined in the template document. That's why I said that = section=20 still have some concepts about the templates. 
[MB] Okay, = now I see=20 your specific concern.  Would it be clearer and less = confusing if=20 we just drop "additional" from that sentence? =20 [/MB] 
 
[ON] = Actually the=20 problem is not only in that sentence although in all the section. I=20 recommend you to re-write a bit more all section 5.1. In previous = e-mails I=20 sent you a text for section 5.1. You could use that text if you = think is=20 suitable for your draft. 
&nbs= p;
[MB2] But, I think that initial = suggestion was=20 missing the point that the model in the framework must=20 support clients that just support only the data in = the=20  SIPPING event pkg and that don't support the data model = define=20 [17 - the XCON data model].  Those paragraphs are intended to = provide=20 the justification for defining additional data beyond that provided=20
by the SIPPING event package.=20
&nbs= p;
I did make some other slight changes to = that text=20 here's the OLD/NEW of that 2nd paragraph in section=20 5.1:
OLD:=
   In order to support more = complex media=20 manipulations and enhanced
   conferencing features the = common=20 conference information contains
   additional data, = beyond that=20 defined in [10].  The data model defined
   in = [17] would=20 be the basis for conferencing systems supporting
   = enhanced=20 conferencing features.  The additional information=20 defined
   in [17] provides the details of the specific = media=20 mixing details,
   the associated client roles and the=20 available floor controls.  This
   information = would allow=20 authorized clients to manipulate the mixer's
   = behavior via=20 the focus, and the resultant distribution of the = media
   to=20 all or individual participants.  By doing so, a client can=20 change
   its own state and/or state of other = participants in=20 the conference.
&nbs= p;
&nbs= p;
NEW:=
   In=20 order to support more complex media manipulations and=20 enhanced
   conferencing features the conference = information,=20 as reflected by = the 
   data model defined in [17], = contains=20 additional
   data beyond that defined in [10].  = The=20 information defined in [17] =
  =20 provides=20 specific media mixing details,=20
   available floor controls and = other data=20 necessary to support enhanced=20
   conferencing = features.  This=20 information allows
   authorized clients to manipulate = the=20 mixer's behavior via the focus,
   with the = resultant=20 distribution of the media to all or individual
  =20 participants.  By doing so, a client can change its own state=20 and/or
   state of other participants in the=20 conference.
 
[/MB2]
&nbs= p;
&nbs= p;
------_=_NextPart_001_01C79642.D349965C-- --===============0092321679== 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 --===============0092321679==-- From xcon-bounces@ietf.org Tue May 15 03:04:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnr56-0001An-B2; Tue, 15 May 2007 03:04:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnr54-0001Af-H8 for xcon@ietf.org; Tue, 15 May 2007 03:04:22 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnr53-0001Qd-2n for xcon@ietf.org; Tue, 15 May 2007 03:04:22 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6559921101; Tue, 15 May 2007 09:04:20 +0200 (CEST) X-AuditID: c1b4fb3e-af1edbb0000061ca-4c-46495b74d14f Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 45E682121C; Tue, 15 May 2007 09:04:20 +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, 15 May 2007 09:04:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 May 2007 09:03:26 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More comments on draft-ietf-xcon-framework-07.txt Thread-Index: AceHPwmeREeU/PqhQJ2OLBJG23H9ywALOemwAOICnhAACayuQALF/WiwAAHwkSAAISyoIA== References: From: "Oscar Novo \(JO/LMF\)" To: "Mary Barnes" , X-OriginalArrivalTime: 15 May 2007 07:04:20.0069 (UTC) FILETIME=[426CB950:01C796BF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 559439f19b20fd64c5cd872aef84c6f3 Cc: cboulton@ubiquitysoftware.com Subject: [XCON] RE: More comments on draft-ietf-xcon-framework-07.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: , Content-Type: multipart/mixed; boundary="===============0151997881==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0151997881== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C796BF.22B7F6B0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C796BF.22B7F6B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Now it's a bit more clear. For me it's fine like that. =20 Thanks, =20 Oscar ________________________________ From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: 14. toukokuuta 2007 19:14 To: Oscar Novo (JO/LMF); xcon@ietf.org Cc: cboulton@ubiquitysoftware.com Subject: RE: More comments on draft-ietf-xcon-framework-07.txt One more comment below [MB2]. =20 =20 Mary=20 -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]=20 Sent: Monday, May 14, 2007 9:22 AM To: Barnes, Mary (RICH2:AR00); xcon@ietf.org Cc: cboulton@ubiquitysoftware.com Subject: RE: More comments on draft-ietf-xcon-framework-07.txt =09 =09 Mary, =20 Comments inline as [ON] =20 Regards, =20 Oscar =09 =09 ________________________________ From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: 30. huhtikuuta 2007 14:37 To: Oscar Novo (JO/LMF); xcon@ietf.org Cc: cboulton@ubiquitysoftware.com Subject: RE: More comments on draft-ietf-xcon-framework-07.txt =09 =09 Hi Oscar, =20 Responses embedded below [MB]. =20 Thanks, Mary=20 =09 -----Original Message----- From: Oscar Novo (JO/LMF) [mailto:oscar.novo@ericsson.com]=20 Sent: Monday, April 30, 2007 2:57 AM To: Barnes, Mary (RICH2:AR00); xcon@ietf.org Cc: cboulton@ubiquitysoftware.com Subject: RE: More comments on draft-ietf-xcon-framework-07.txt =09 =09 Hi Mary,=20 =20 I have just a coupled of comments. =20 - I still think the replacement of the "common conference information" for "conference information data model" is important. Now, this concept is only defined in the framework and it can be very confusing for the readers. I don't think the substitution of this term will impact the whole text. In the framework you have this term only in 20 places, mainly in the 'terminology' and the 'centralized conferencing data model' section.=20 [MB] I do understand how the term "common" has lost its original context since we no longer have the templates, thus there's only one set of information. But, a global replacement won't work quite right, at least in terms of the basic definition, where the "common conference information" is defined as:=20 " The common conference information is the data type (i.e., the XML schema) for a conference object". =20 How about we just drop the phrase "common" and refer to it as "Conference Information"? [/MB]=20 =20 [ON] OK, for me it's fine if we change "Common Conference Information" for "Conference Information" =20 - Regarding section 5.1 there is some text not clear and very confuse, for instance:=20 "The data model defined in [17] would be the basis for conferencing systems supporting enhanced conferencing features.The additional information defined in [17] provides the details of the specific media mixing details, the associated client roles and the available floor controls".=20 The data model doesn't define any additional information. That was defined in the template document. That's why I said that section still have some concepts about the templates.=20 [MB] Okay, now I see your specific concern. Would it be clearer and less confusing if we just drop "additional" from that sentence? [/MB]=20 =20 [ON] Actually the problem is not only in that sentence although in all the section. I recommend you to re-write a bit more all section 5.1. In previous e-mails I sent you a text for section 5.1. You could use that text if you think is suitable for your draft.=20 =20 [MB2] But, I think that initial suggestion was missing the point that the model in the framework must support clients that just support only the data in the SIPPING event pkg and that don't support the data model define [17 - the XCON data model]. Those paragraphs are intended to provide the justification for defining additional data beyond that provided=20 by the SIPPING event package.=20 =20 I did make some other slight changes to that text here's the OLD/NEW of that 2nd paragraph in section 5.1: OLD: In order to support more complex media manipulations and enhanced conferencing features the common conference information contains additional data, beyond that defined in [10]. The data model defined in [17] would be the basis for conferencing systems supporting enhanced conferencing features. The additional information defined in [17] provides the details of the specific media mixing details, the associated client roles and the available floor controls. This information would allow authorized clients to manipulate the mixer's behavior via the focus, and the resultant distribution of the media to all or individual participants. By doing so, a client can change its own state and/or state of other participants in the conference. =20 =20 NEW: In order to support more complex media manipulations and enhanced conferencing features the conference information, as reflected by the=20 data model defined in [17], contains additional data beyond that defined in [10]. The information defined in [17]=20 provides specific media mixing details,=20 available floor controls and other data necessary to support enhanced=20 conferencing features. This information allows authorized clients to manipulate the mixer's behavior via the focus, with the resultant distribution of the media to all or individual participants. By doing so, a client can change its own state and/or state of other participants in the conference. =20 [/MB2] =20 =20 ------_=_NextPart_001_01C796BF.22B7F6B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Now=20 it's a bit more clear. For me it's fine like that.
 
Thanks,
 
Oscar

From: Mary Barnes=20 [mailto:mary.barnes@nortel.com]
Sent: 14. toukokuuta 2007=20 19:14
To: Oscar Novo (JO/LMF); xcon@ietf.org
Cc:=20 cboulton@ubiquitysoftware.com
Subject: RE: More comments on=20 draft-ietf-xcon-framework-07.txt

One=20 more comment below [MB2]. 
 
Mary =
-----Original Message-----
From: = Oscar Novo=20 (JO/LMF) [mailto:oscar.novo@ericsson.com]
Sent: Monday, May = 14,=20 2007 9:22 AM
To: Barnes, Mary (RICH2:AR00);=20 xcon@ietf.org
Cc: = cboulton@ubiquitysoftware.com
Subject:=20 RE: More comments on = draft-ietf-xcon-framework-07.txt

Mary,
 
Comments inline as [ON]
 
Regards,
 
Oscar

From: Mary Barnes=20 [mailto:mary.barnes@nortel.com]
Sent: 30. huhtikuuta 2007=20 14:37
To: Oscar Novo (JO/LMF); xcon@ietf.org
Cc:=20 cboulton@ubiquitysoftware.com
Subject: RE: More comments on=20 draft-ietf-xcon-framework-07.txt

Hi=20 Oscar,
 
Responses embedded below = [MB].
 
Thanks,
Mary =
-----Original Message-----
From: = Oscar Novo=20 (JO/LMF) [mailto:oscar.novo@ericsson.com]
Sent: Monday, = April 30,=20 2007 2:57 AM
To: Barnes, Mary (RICH2:AR00);=20 xcon@ietf.org
Cc: = cboulton@ubiquitysoftware.com
Subject:=20 RE: More comments on = draft-ietf-xcon-framework-07.txt

Hi=20 Mary,
 
I=20 have just a coupled of comments.
 
- I still think the replacement of = the "common=20 conference information" for "conference information data model" is=20 important. Now, this concept is only defined in the framework and it = can be=20 very confusing for the readers. I don't think the substitution of = this term=20 will impact the whole text. In the framework you have this term only = in 20=20 places, mainly in the 'terminology' and the 'centralized = conferencing=20 data model' section. 
[MB] I do=20 understand how the term "common" has lost its original context since = we no=20 longer have the templates, thus there's only one set of information. = But, a global replacement won't work quite right, at least = in=20 terms of the basic definition, where the "common conference=20 information" is defined as:
   " The=20 common
      conference information is = the data=20 type (i.e., the XML schema) for
      a=20 conference object". 
How about = we just drop=20 the phrase "common" and refer to it as "Conference=20 Information"?
[/MB] 
&nbs= p;
[ON] OK, for me it's fine if we change "Common Conference = Information" for "Conference=20 Information"
 
- Regarding section 5.1 there is some text not clear = and very=20 confuse, for instance:
"The data model defined in [17] would be the basis = for=20 conferencing systems supporting enhanced conferencing = features.The additional information defined in = [17] = provides the details of=20 the specific media mixing details, the associated client roles and = the=20 available floor controls".
The data model doesn't define any additional = information. That=20 was defined in the template document. That's why I said that = section=20 still have some concepts about the templates. 
[MB] Okay, = now I see=20 your specific concern.  Would it be clearer and less = confusing if=20 we just drop "additional" from that sentence? =20 [/MB] 
 
[ON] = Actually the=20 problem is not only in that sentence although in all the section. I=20 recommend you to re-write a bit more all section 5.1. In previous = e-mails I=20 sent you a text for section 5.1. You could use that text if you = think is=20 suitable for your draft. 
&nbs= p;
[MB2] But, I think that initial = suggestion was=20 missing the point that the model in the framework must=20 support clients that just support only the data in = the=20  SIPPING event pkg and that don't support the data model = define=20 [17 - the XCON data model].  Those paragraphs are intended to = provide=20 the justification for defining additional data beyond that provided=20
by the SIPPING event package.=20
&nbs= p;
I did make some other slight changes to = that text=20 here's the OLD/NEW of that 2nd paragraph in section=20 5.1:
OLD:=
   In order to support more = complex media=20 manipulations and enhanced
   conferencing features the = common=20 conference information contains
   additional data, = beyond that=20 defined in [10].  The data model defined
   in = [17] would=20 be the basis for conferencing systems supporting
   = enhanced=20 conferencing features.  The additional information=20 defined
   in [17] provides the details of the specific = media=20 mixing details,
   the associated client roles and the=20 available floor controls.  This
   information = would allow=20 authorized clients to manipulate the mixer's
   = behavior via=20 the focus, and the resultant distribution of the = media
   to=20 all or individual participants.  By doing so, a client can=20 change
   its own state and/or state of other = participants in=20 the conference.
&nbs= p;
&nbs= p;
NEW:=
   In=20 order to support more complex media manipulations and=20 enhanced
   conferencing features the conference = information,=20 as reflected by = the 
   data model defined in [17], = contains=20 additional
   data beyond that defined in [10].  = The=20 information defined in [17] =
  =20 provides=20 specific media mixing details,=20
   available floor controls and = other data=20 necessary to support enhanced=20
   conferencing = features.  This=20 information allows
   authorized clients to manipulate = the=20 mixer's behavior via the focus,
   with the = resultant=20 distribution of the media to all or individual
  =20 participants.  By doing so, a client can change its own state=20 and/or
   state of other participants in the=20 conference.
 
[/MB2]
&nbs= p;
&nbs= p;
------_=_NextPart_001_01C796BF.22B7F6B0-- --===============0151997881== 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 --===============0151997881==-- From xcon-bounces@ietf.org Tue May 15 18:50:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho5qR-00061J-EI; Tue, 15 May 2007 18:50:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ho5qE-0005gM-HZ; Tue, 15 May 2007 18:50:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ho5qE-0001ng-3C; Tue, 15 May 2007 18:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 11D5D3294A; Tue, 15 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ho5qD-00042k-Tx; Tue, 15 May 2007 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 15 May 2007 18:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-framework-08.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 : A Framework for Centralized Conferencing Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-framework-08.txt Pages : 63 Date : 2007-5-15 This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in a centralized unicast conference. The Centralized Conferencing Framework defines logical entities and naming conventions, along with a high level conferencing data model. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-xcon-framework-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-xcon-framework-08.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-5-15155039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-framework-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-framework-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-15155039.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 May 16 11:48:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoLkD-0002xv-3y; Wed, 16 May 2007 11:48:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoLkC-0002vF-G5 for xcon@ietf.org; Wed, 16 May 2007 11:48:52 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoLkB-0004EA-2l for xcon@ietf.org; Wed, 16 May 2007 11:48:52 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l4GFloI27891 for ; Wed, 16 May 2007 15:47:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [XCON] I-D ACTION:draft-ietf-xcon-framework-08.txt Date: Wed, 16 May 2007 10:48:43 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] I-D ACTION:draft-ietf-xcon-framework-08.txt Thread-Index: AceXQ25GQ8DGDqMxQgSgnoqZ9uQAwwAjBt/g From: "Mary Barnes" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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 all, =20 This update reflects the recent feedback on the document from the mailing list and updated the template to include the Intended status as Informational. Here's a summary of the changes: 1) added Intended Status as Informational 2) Removed data model from Title and clarified reference to data model in this document as "high level data model". Renamed section 5 from "Centralized Conferencing Data Model" to "Centralized Conferencing Data".=20 3) deleted Conventions section with reference to 2119. 4) Moved terminology to just after intro, before overview 5) Changed "Common Conference Information" to "Conference Information".=20 6) Removed references to policies as an integral part of data model: updated text discussing policies in section 5 and section 5.2, with section 7 text changed to be consistent with the updated text in section 5 and 5.2. =20 7) Removal of references to individual conference-URI and Userid documents, bringing some background back into the framework, since those identifiers are defined in the data model.=20 8) Miscellaneous editorial nits.=20 And, here's a link to the diff: http://tools.ietf.org/wg/xcon/draft-ietf-xcon-framework/draft-ietf-xcon- framework-08-from-07.diff.html The majority of the deltas are due to removing references and thus reference numbers changing and removing the 2119 section and thus section numbers changing.=20 There is still one error in the doc since I removed the 2119 reference there was still a capatilized MUST in the security section. But, I think that fix can wait until the chairs have done their PROTO review, and I'll fix that with any other concerns that arise from that review.=20 Other than that one error, I think the document is ready for IESG review.=20 Thanks, Mary -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Tuesday, May 15, 2007 5:50 PM To: i-d-announce@ietf.org Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-framework-08.txt A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : A Framework for Centralized Conferencing Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-framework-08.txt Pages : 63 Date : 2007-5-15 =09 This document defines the framework for Centralized Conferencing. The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber and PSTN, to exchange media in a centralized unicast conference. The Centralized Conferencing Framework defines logical entities and naming conventions, along with a high level conferencing data model. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-08.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of=20 the message.=20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the=20 username "anonymous" and a password of your e-mail address. After=20 logging in, type "cd internet-drafts" and then=20 "get draft-ietf-xcon-framework-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-xcon-framework-08.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu May 17 02:22:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoZNz-0005oh-D9; Thu, 17 May 2007 02:22:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoZNy-0005oZ-7V for xcon@ietf.org; Thu, 17 May 2007 02:22:50 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoZNt-0007B9-TQ for xcon@ietf.org; Thu, 17 May 2007 02:22:47 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 699F420677 for ; Thu, 17 May 2007 08:22:45 +0200 (CEST) X-AuditID: c1b4fb3c-a84eabb0000073d5-5e-464bf4b5b420 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5731C20608 for ; Thu, 17 May 2007 08:22:45 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 May 2007 08:22:45 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 May 2007 08:22:45 +0200 Received: from [131.160.126.214] (rvi2-126-214.lmf.ericsson.se [131.160.126.214]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C56B1246F for ; Thu, 17 May 2007 09:22:44 +0300 (EEST) Message-ID: <464BF4B4.8050804@ericsson.com> Date: Thu, 17 May 2007 09:22:44 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: XCON Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2007 06:22:45.0176 (UTC) FILETIME=[C82DC380:01C7984B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [XCON] Thread on nicknames in SIMPLE 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, FYI: there is an ongoing thread in SIMPLE dealing with nicknames that may be relevant to what we do in XCON. The thread starts here: http://www1.ietf.org/mail-archive/web/simple/current/msg07175.html In particular, the discussion about the uniqueness properties of nicknames seems to be especially interesting for this group. Cheers, Gonzalo _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu May 17 11:01: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 1HohUM-0001Qy-Cx; Thu, 17 May 2007 11:01:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HohUK-0001Qq-Q8 for xcon@ietf.org; Thu, 17 May 2007 11:01:56 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HohUG-0000q0-5N for xcon@ietf.org; Thu, 17 May 2007 11:01:56 -0400 Received: from rly24b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly24b.srv.mailcontrol.com (MailControl) with ESMTP id l4HF1fpu030635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 May 2007 16:01:46 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly24b.srv.mailcontrol.com (MailControl) id l4HF0trg027547 for xcon@ietf.org; Thu, 17 May 2007 16:00:55 +0100 Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly24b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id l4HF0iL9027098; Thu, 17 May 2007 16:00:55 +0100 (BST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 May 2007 16:00:43 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Conference Control Package Thread-Index: AceYlCTuNlMenbKrSE+jOgdsAaIuYA== From: "Chris Boulton" To: X-Scanned-By: MailControl A-07-07-00 (www.mailcontrol.com) on 10.66.1.134 X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: Alan Johnston , adam@nostrum.com Subject: [XCON] Conference Control 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="===============0866457114==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0866457114== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79894.2492D5E6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C79894.2492D5E6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable XCONers, =20 The authors have submitted a new Conference Control package for early discussion in the XCON work group. The intention is that this draft is a complimentary technology to the previously submitted CCMP work (use of SOAP). All comments welcome. Until it appears in the archives you can get a copy from the following link: http://www.ubiquitysoftware.com/mediactrl/draft-boulton-xcon-conference- control-package-00.txt. =20 Best Regards. =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_01C79894.2492D5E6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

XCONers,

 

The authors have submitted a new Conference Contr= ol package for early discussion in the XCON work group.  The intention is that this draft is a complimentary technology to the previously submitted C= CMP work (use of SOAP).  All comments welcome.  Until it appears in t= he archives you can get a copy from the following link: http://www.ubiquitysoftware.com/mediactrl/draf= t-boulton-xcon-conference-control-package-00.txt.

 

Best Regards.

 

Chris.

 

 



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_01C79894.2492D5E6-- --===============0866457114== 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 --===============0866457114==-- From xcon-bounces@ietf.org Thu May 17 11:17:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HohjO-0004Lm-F3; Thu, 17 May 2007 11:17:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HohjM-0004I9-RN for xcon@ietf.org; Thu, 17 May 2007 11:17:29 -0400 Received: from fw.polycom.co.il ([212.179.41.2] helo=isrexch01.israel.polycom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HohjK-0003H8-Nx for xcon@ietf.org; Thu, 17 May 2007 11:17:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] Conference Control Package Date: Thu, 17 May 2007 18:18:01 +0300 Message-ID: <144ED8561CE90C41A3E5908EDECE315C0495B658@IsrExch01.israel.polycom.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Conference Control Package Thread-Index: AceYlCTuNlMenbKrSE+jOgdsAaIuYAAAfvuA From: "Even, Roni" To: "Chris Boulton" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd Cc: adam@nostrum.com, Alan Johnston 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="===============1798784714==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1798784714== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C79896.905C93EA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C79896.905C93EA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chris, =20 Is the architecture direction you are suggesting here is to use the same package for XCON and Mediactrl.=20 What I mean is from an XCON user to XCON Conference server to the Media server. =20 Roni Even =20 =20 =20 ________________________________ From: Chris Boulton [mailto:cboulton@ubiquity.net]=20 Sent: Thursday, May 17, 2007 6:01 PM To: xcon@ietf.org Cc: Alan Johnston; adam@nostrum.com Subject: [XCON] Conference Control Package =20 XCONers, =20 The authors have submitted a new Conference Control package for early discussion in the XCON work group. The intention is that this draft is a complimentary technology to the previously submitted CCMP work (use of SOAP). All comments welcome. Until it appears in the archives you can get a copy from the following link: http://www.ubiquitysoftware.com/mediactrl/draft-boulton-xcon-conference- control-package-00.txt. =20 Best Regards. =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_01C79896.905C93EA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Chris,

 

Is the architecture direction you = are suggesting here is to use the same package for XCON and Mediactrl. =

What I mean is from an XCON user to = XCON Conference server to the Media server.

 

Roni = Even

 

 

 

From: Chris = Boulton [mailto:cboulton@ubiquity.net]
Sent: Thursday, May 17, = 2007 6:01 PM
To: xcon@ietf.org
Cc: Alan Johnston; adam@nostrum.com
Subject: [XCON] = Conference Control Package

 

XCONers,

 

The authors have submitted a new Conference = Control package for early discussion in the XCON work group.  The intention = is that this draft is a complimentary technology to the previously = submitted CCMP work (use of SOAP).  All comments welcome.  Until it appears = in the archives you can get a copy from the following link: http://www.ubiquitysoftware.com/mediactrl/= draft-boulton-xcon-conference-control-package-00.txt.

 

Best Regards.

 

Chris.

 

 




<= /p>

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_01C79896.905C93EA-- --===============1798784714== 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 --===============1798784714==-- From xcon-bounces@ietf.org Thu May 17 12:59:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojKL-00059K-Sd; Thu, 17 May 2007 12:59:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HojKK-00058P-JA for xcon@ietf.org; Thu, 17 May 2007 12:59:44 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HojKI-0007Em-GN for xcon@ietf.org; Thu, 17 May 2007 12:59:44 -0400 Received: from rly13b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly13b.srv.mailcontrol.com (MailControl) with ESMTP id l4HGxcdU026978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 May 2007 17:59:38 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly13b.srv.mailcontrol.com (MailControl) id l4HGwt7x025053 for xcon@ietf.org; Thu, 17 May 2007 17:58:55 +0100 Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly13b-eth0.srv.mailcontrol.com (envelope-sender cboulton@ubiquity.net) (MIMEDefang) with ESMTP id l4HGwsH3025002; Thu, 17 May 2007 17:58:55 +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] Conference Control Package Date: Thu, 17 May 2007 17:58:53 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Conference Control Package Thread-Index: AceYlCTuNlMenbKrSE+jOgdsAaIuYAAAfvuAAAOT6OA= From: "Chris Boulton" To: "Even, Roni" , X-Scanned-By: MailControl A-07-07-05 (www.mailcontrol.com) on 10.66.1.123 X-Spam-Score: 0.0 (/) X-Scan-Signature: 58b614506802734014829a093beb6879 Cc: adam@nostrum.com, Alan Johnston 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="===============2073127283==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============2073127283== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C798A4.A67CE75B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C798A4.A67CE75B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Chris, =20 Is the architecture direction you are suggesting here is to use the same package for XCON and Mediactrl.=20 What I mean is from an XCON user to XCON Conference server to the Media server. =20 [Chris Boulton] Not in this draft. This re-uses the MediaCtrl Control Framework and just uses the bindings as specified in CCMP. I probably need to work on the draft names :-). =20 Chris. =20 =20 Roni Even =20 =20 =20 _____ =20 From: Chris Boulton [mailto:cboulton@ubiquity.net]=20 Sent: Thursday, May 17, 2007 6:01 PM To: xcon@ietf.org Cc: Alan Johnston; adam@nostrum.com Subject: [XCON] Conference Control Package =20 XCONers, =20 The authors have submitted a new Conference Control package for early discussion in the XCON work group. The intention is that this draft is a complimentary technology to the previously submitted CCMP work (use of SOAP). All comments welcome. Until it appears in the archives you can get a copy from the following link: http://www.ubiquitysoftware.com/mediactrl/draft-boulton-xcon-conference- control-package-00.txt. =20 Best Regards. =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_01C798A4.A67CE75B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Chris,

 

Is the architecture direction you are suggesting here is to use the same = package for XCON and Mediactrl.

What I mean is from an XCON user to XCON Conference server to the Media = server.

 

[Chris Boulton] Not in this draft.  This re-uses = the MediaCtrl Control Framework and just uses the bindings as specified in CCMP.  = I probably need to work on the draft names J= .

 

Chris.

 

 

Roni Even

 

 

 

From: Chris Boulton [mailto:cboulton@ubiquity.net]
Sent: Thursday, May 17, 2007 6:01 = PM
To: xcon@ietf.org
Cc: Alan Johnston; adam@nostrum.com
Subject: [XCON] = Conference Control Package

 

XCONers,

 

The authors = have submitted a new Conference Control package for early discussion in the = XCON work group.  The intention is that this draft is a complimentary technology to the previously submitted CCMP work (use of SOAP).  = All comments welcome.  Until it appears in the archives you can get a = copy from the following link: http://www.ubiquitysoftware.com/mediactrl/= draft-boulton-xcon-conference-control-package-00.txt.

 

Best = Regards.

 

Chris.

 

 





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_01C798A4.A67CE75B-- --===============2073127283== 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 --===============2073127283==-- From xcon-bounces@ietf.org Thu May 24 11:34:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrFKf-00021i-L0; Thu, 24 May 2007 11:34:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrFKe-00021c-Is for xcon@ietf.org; Thu, 24 May 2007 11:34:28 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrFKd-0006ID-AD for xcon@ietf.org; Thu, 24 May 2007 11:34:28 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l4OFYFF24225; Thu, 24 May 2007 15:34:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 May 2007 10:34:00 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XCON meeting at IETF-69 Thread-Index: AceeGPOxOSATVey9T2Cd4lj5K1YM4A== From: "Mary Barnes" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: xcon@ietf.org Subject: [XCON] XCON meeting at IETF-69 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 don't see XCON on the agenda yet:=20 https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=3D= 69 Is it not planned to meet? I thought this past Monday was the cutoff for initial requests.=20 =20 We will be updating the CCMP document, as well as the MSRP-conferencing (although, per the comments at IETF-68, we will make it more general). I guess we can just discuss on the list if we don't face-to-face time, but I had also assumed we'd be closing off on the data-model and moving forward with discussing the protocol. Thanks, Mary _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu May 24 12:03:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrFn5-0004ZK-Oq; Thu, 24 May 2007 12:03:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrFn4-0004ZF-Hy for xcon@ietf.org; Thu, 24 May 2007 12:03:50 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrFn3-0003FT-AF for xcon@ietf.org; Thu, 24 May 2007 12:03:50 -0400 Received: from 24-107-197-43.dhcp.stls.mo.charter.com ([24.107.197.43] helo=[192.168.0.39]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1HrFn0-000AwI-5B; Thu, 24 May 2007 12:03:46 -0400 X-MHO-User: U2FsdGVkX1/dlq3jbU9BtUZxjnmrEKN65njMaky4IiI= X-MHO-User: U2FsdGVkX19LsJwyJrLhhGX28ZMMK0Yvm9xVBvaAuXM= X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.197.43 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/fCaZrSIzVTY3SHXnlz/xknFn4Sjh79Eo= Message-ID: <4655B76F.8040701@sipstation.com> Date: Thu, 24 May 2007 11:03:59 -0500 From: Alan Johnston User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Mary Barnes Subject: Re: [XCON] XCON meeting at IETF-69 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: b19722fc8d3865b147c75ae2495625f2 Cc: adam@nostrum.com, xcon@ietf.org X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org Hi Mary, The plan is to meet - we got our request in a little late. XCON should show up on the next version of the agenda. Thanks, Alan Mary Barnes wrote: > I don't see XCON on the agenda yet: > https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num= > 69 > > Is it not planned to meet? I thought this past Monday was the cutoff for > initial requests. > > We will be updating the CCMP document, as well as the MSRP-conferencing > (although, per the comments at IETF-68, we will make it more general). > I guess we can just discuss on the list if we don't face-to-face time, > but I had also assumed we'd be closing off on the data-model and moving > forward with discussing the protocol. > > Thanks, > 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