From xcon-bounces@ietf.org Wed Jun 21 06:52:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0Jy-0000xY-Ml; Wed, 21 Jun 2006 06:52:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft0Jw-0000xO-PF for xcon@ietf.org; Wed, 21 Jun 2006 06:52:28 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft0Jt-0004sd-32 for xcon@ietf.org; Wed, 21 Jun 2006 06:52:28 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3B099ED8; Wed, 21 Jun 2006 12:52:24 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 12:52:23 +0200 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 12:52:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [XCON] Data Model Date: Wed, 21 Jun 2006 12:51:55 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [XCON] Data Model Thread-Index: AcZ1Ugpu0LmAFDekTZCnOORVH4JjSQGdtLXgBlXP4MA= From: "Oscar Novo \(JO/LMF\)" To: "Srivatsa Srinivasan" , "Adam Roach" , "XCON-IETF" X-OriginalArrivalTime: 21 Jun 2006 10:52:23.0525 (UTC) FILETIME=[C6E86950:01C69520] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.3 (/) X-Scan-Signature: 34a12386bc31e4adf7d931eae58f5833 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: , Content-Type: multipart/mixed; boundary="===============0136999644==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============0136999644== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69520.B60B9AC6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69520.B60B9AC6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Srivatsa and Sean for your comments. We have included some of = your comments in the next version of the draft that I will submit on = Monday. If anybody has more comments about the data model draft, please = send to me all of them before monday. One thing that I would like to remark and reading your comments I'm not = sure you've understood this, is that this draft defines an Extensible = Markup Language (XML) Schema that represents the common conference = information in a conference system. It doesn't mean that all this = information have to be defined in a conference system. Only the = information that the conference system supports will be defined in the = data model. How is this information define in the server is out of the = scope of our draft and should be defined in the conference control = protocol or, more generally, in the framework. In the following paragraph I try to answer all your questions and fix = all the errors you=B4ve found in the draft.=20 Thank you very much for your review. Oscar ------------------ Here are comments for the data model draft-ietf-xcon-common-data-model-00. This email incorporates comments = from Sean Olson as well. What follows are some points to be addressed, = in general, throughout the document followed by section-by-section = comments. There are inconsistencies between text, schema and examples for certain = XML elements appearing throughout the document. That is, they are = defined in text, but not in the schema or defined in the examples but = not in the text or schema and such. Also, the document needs to be very = clear as to what the keys are for XML elements appearing in sequences. Need to be consistently explicit about which top-level elements are = mandatory and which are not (in text, rather than relying on schema = definition). It would be useful to also indicate which elements make = sense at conference creation time and which at conference run time. For = readability, it may be beneficial to indicate, in text, which parts of = the document are actually extensible rather than relying on the central = text for XML extensibility through namespaces. No clear indication is given as to how the system/client learns of = supported values for specific enumerations or features in a conferencing = system (see below 8.)? Surely, a conferencing system may not support all = that is defined in this data model, correct? We also need to work through the details of and = elements for a user/endpoint in this document as templates also = define similar concepts. So the following comments will NOT be going = over those elements as these have been brought up elsewhere. 1. Section 3.2 appears to be in text and examples, = but isn't in the schema definition.=20 [ON] Correct. In the next version of the draft this information will = appear in the schema as well. It also seems too limiting to just support four values. The implied FSM = also is wrong.=20 [ON] If you think there are more stages we can define them. How is this any different than ? [ON] The conference state is from the event package and refers to a = running conference. 2. Section 3.2 seems redundant, why not just use = with defined ? [ON] In the "Event Package for Conference State" is already defined like = that and this document has to be align with the "Event Package". 3. Section 3.2.2 and Section 3.2.3, There is no need for and = type of to be changed/redefined from what is = defined in conference event package. Why not just use the URI schema = plus element and make it consistent across all the possible = URI types? [ON] Actually, I remember from the last IETF that some people complain = exactly about what you are proposing here. That's why I change and I = think is much more clear now for a specification prospective like that. = The conference event package only defines SIP parameters. 4. Section 3.2.2 doesn't belong here and it is not defined in = [2]. The restriction on a maximum of 6 phone numbers is also arbitrary. Without some corresponding label or purpose, it will be hard to tell or = describe to the user which phone number to use. Multiple PIN codes = should be supported at a minimum. Alternatively, one may remove this = element for it to appear elsewhere in description or text.=20 Remove any reference to H.320 bonding from the document as it is not = necessary and is currently under-specified as to how this will work. [ON] yes, I will remove the BONDING reference, the element = and the 6 phone number restriction and I will add a new attribute = 'purpose' to the element. 5. Section 3.2.5 The child of is too limiting -- we need to be able to express all the a=3D attributes in SDP that may = accompany a codec if we are to say anything interesting about video = codecs. [ON] This part, as you said in the sentences of your e-mail, is not = well-defined and still the authors of the data model are waiting for the = new update of the template draft to align this elements. Most of the = a=3Dattributes in SDP are not static values and should be defined in the = templates. In the other hand, the m=3Dattributes are static data and = this information are defined in the data model.=20 6. Section 3.5 Please remove entirely. It serves no = useful purpose from either an organize-time or run-time perspective. [ON] The element contains a series of protocol = sub-elements. Each protocol sub-element contains the policy related to = the usage of a particular protocol and we think it's important to keep = this policies in the data model. 7. Section 3.6 Do floors and floor policies really belong here if floor = controls are in templates?=20 [ON] Yes, The static information should be defined in the data model. What is the key?=20 [ON] label is the key. Sorry I forget to put this information in the XML = schema. In the next version of the draft I will put it. Does template refer to floors defined here?=20 [ON] templates should refer throught the 'label' attribute of the data = model to the floors defined there. 8. Section 3.7 What if the conferencing system does not support = on a per-user setting, how is it conveyed?=20 [ON] is not a mandatory element. If the conferencing = system does not support the element, the data model of = this conferencing system does not have to define this element. What if only a subset of joining methods is supported by the system (how = would the client know what to choose from the UI)?=20 [ON] Then, the data model only would define the methods it supports. It = is out of the scope of this draft to define how to do this. This = information should be defined in the "conference control protocol" = draft. Would an organizer have to try all possible choices before choosing the = one that is supported for a given user?=20 [ON] No, the organizer has to define the action if the user does not = support this action, the user can not join the conference.=20 What about extensibility here? Same applies to other lists and features. [ON] The extensibility of this list or other lists in the model is = defined in Section 5 of the document. 9. Section 3.7 Make explicitly fall under an = admission-policy element.=20 [ON] the child element is closed related with = the defined in the same element. Still it's important to = keep both of them together.=20 Also, the schema does not appear to define=20 this element. Rename to something more meaningful: like = 'closedAuthenticated' when users must be specified (and authenticated)=20 and 'openAuthenticated' when users can be added after conference = activation. =20 =20 [ON] I have changed the element for the one = you said here. 10. Section 3.7.1.1 Can we cut for the first version of the = model? This can be achieved through simpler operations without = complicating the data model itself =20 [ON] When XCOn defines this operations that you mention we will cut it = from the data model.=20 11. Section 3.7.2 What does a domain mean in the ? (How = do you enumerate the entities to dial out to?) =20 [ON] Yes, true. I will remove it from the next version. 12. Section 3.7.2 Why differentiate between and = ? It's clear that the Focus will act differently, just don't = see the need to explicitly control this difference in behavior. This = seems more reasonable to leave up to the implementation.=20 [ON] For a matter of clarity.=20 13. Section 3.7.2 , and can = be restructured and combined into one list. That is, have a list with = all users in it and then enlist allowed joining-method's referencing the = available or supported joining-methods in the conferencing system. Make = it extensible to support an 'auto' joining method to accomplish previous = comment in (12).=20 [ON] previous comment in (12) 14. Section 3.7.4 The seems too generic to be = implemented in a reasonably interoperable fashion. It also seems to = bloat the data model. [ON] I would be glad to read new ideas about the specification of this = element in the data model. I know that this solution is not the best one = but, at least, works.=20 Also, the conditions are ambiguous in several cases. For example, = (section 3.7.4.2.1.10) may be meaningless in many = conferences.=20 How would this condition be interpreted in a conference that has no = notion of passcodes? [ON] If the conference system does not have any notion of passcode, it = will not have this rule in its data model. 15. Section 3.7.5 The element is too limiting = ...Digest/Digest-AKA do not even begin to scratch the surface of = possibilities. Perhaps more importantly, there is no use-case for this = being in the data model at all as it may be derived from other elements = like and/or . [ON] I have removed this element from the data model.=20 16. There are several elements in the document that may require = role-based definitions. For example, take . An organizer = may want one set of service uri entries for presenters, but a *different* set of entries for attendees. Similarly, in some cases, one = may want to display different display-text based on whether the user is = a presenter or the user is an attendee. How would one achieve that?=20 [ON] I guess that we could use the element in the = example that you mention. 17. Minor XML schema point: when defining XML elements and their types = in schema, it's generally better to use the full name followed by a = "-type" to remain consistent. In the schema definition for the data = model, this has inconsistently been followed. For example: and elsewhere as [ON] thanks, I have fixed that typo. Srivatsa ------_=_NextPart_001_01C69520.B60B9AC6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks Srivatsa and Sean for your comments. We have = included=20 some of your comments in the next version of the draft that I will = submit on=20 Monday. If anybody has more comments about the data model draft, please = send to=20 me all of them before monday.

One thing that I would like to remark and reading your = comments=20 I'm not sure you've understood this, is that this draft defines an = Extensible=20 Markup Language (XML) Schema that represents the common conference = information=20 in a conference system. It doesn't mean that all this information have = to be=20 defined in a conference system. Only the information that the conference = system=20 supports will be defined in the data model. How is this information = define in=20 the server is out of the scope of our draft and should be defined in the = conference control protocol or, more generally, in the framework.
In = the=20 following paragraph I try to answer all your questions and fix all the = errors=20 you=B4ve found in the draft.

Thank you very much for your review.

Oscar

------------------

Here = are comments=20 for the data model
draft-ietf-xcon-common-data-model-00. This email=20 incorporates comments from Sean Olson as well. What follows are some = points to=20 be addressed, in general, throughout the document followed by = section-by-section=20 comments.

There are inconsistencies between text, schema and = examples for=20 certain XML elements appearing throughout the document. That is, they = are=20 defined in text, but not in the schema or defined in the examples but = not in the=20 text or schema and such. Also, the document needs to be very clear as to = what=20 the keys are for XML elements appearing in sequences.
Need to be = consistently=20 explicit about which top-level elements are mandatory and which are not = (in=20 text, rather than relying on schema definition). It would be useful to = also=20 indicate which elements make sense at conference creation time and which = at=20 conference run time. For readability, it may be beneficial to indicate, = in text,=20 which parts of the document are actually extensible rather than relying = on the=20 central text for XML extensibility through namespaces.

No clear=20 indication is given as to how the system/client learns of supported = values for=20 specific enumerations or features in a conferencing system (see below = 8.)?=20 Surely, a conferencing system may not support all that is defined in = this data=20 model, correct?

We also need to work through the details of=20 <available-media> and <media> elements for a user/endpoint = in this=20 document as templates also define similar concepts. So the following = comments=20 will NOT be going over those elements as these have been brought up=20 elsewhere.

1. = Section 3.2=20 <conference-stage> appears to be in text and examples, but isn't = in the=20 schema definition.

[ON] Correct. In the next = version of the=20 draft this information will appear in the schema as = well.

It also seems too limiting to = just support=20 four values. The implied FSM also is wrong.

[ON] If you think there are more = stages we=20 can define them.

How is this any different than=20 <conference-state>?

[ON] The conference state is = from the event=20 package and refers to a running conference.

2. Section 3.2 <web-page> = seems=20 redundant, why not just use <service-uris> with defined=20 <purpose>?

[ON] In the "Event Package for = Conference=20 State" is already defined like that and this document has to be align = with the=20 "Event Package".


3. Section 3.2.2 and Section 3.2.3, There is no need for=20 <conf-uris> and <service-uris> type of <uris-type> to = be=20 changed/redefined from what is defined in conference event package. Why = not just=20 use the URI schema plus <purpose> element and make it consistent = across=20 all the possible URI types?

[ON] Actually, I remember from the last IETF that some people = complain=20 exactly about what you are proposing here. That's why I change and I = think is=20 much more clear now for a specification prospective like that. The = conference=20 event package only defines SIP parameters.

4. Section 3.2.2 <PIN-code> doesn't belong here and it is not = defined=20 in [2]. The restriction on a maximum of 6 phone numbers is also=20 arbitrary.
Without some corresponding label or purpose, it will be = hard to=20 tell or describe to the user which phone number to use.  Multiple = PIN codes=20 should be supported at a minimum. Alternatively, one may remove this = element for=20 it to appear elsewhere in description or text.
Remove any reference = to H.320=20 bonding from the document as it is not necessary and is currently=20 under-specified as to how this will work.

[ON] yes, I will remove the BONDING reference, the <PIN-code> = element=20 and the 6 phone number restriction and I will add a new attribute = 'purpose' to=20 the <PSTN/ISDN> element.

5. Section 3.2.5 The <codecs> child of <available-media> = is too=20 limiting
-- we need to be able to express all the a=3D attributes in = SDP that=20 may accompany a codec if we are to say anything interesting about video=20 codecs.

[ON] This part, as you said in the sentences of your e-mail, is not=20 well-defined and still the authors of the data model are waiting for the = new=20 update of the template draft to align this elements. Most of the = a=3Dattributes in=20 SDP are not static values and should be defined in the templates. In the = other=20 hand, the m=3Dattributes are static data and this information are = defined in the=20 data model.

6. Section 3.5 Please remove <security-mechanism> entirely. It = serves=20 no useful purpose from either an organize-time or run-time = perspective.

[ON] The <security-mechanism> element contains a series of = protocol=20 sub-elements. Each protocol sub-element contains the policy related to = the usage=20 of a particular protocol and we think it's important to keep this = policies in=20 the data model.

7. Section 3.6 Do floors and floor policies really belong here if = floor=20 controls are in templates?

[ON] Yes, The static information should be defined in the data = model.

What is the key?

[ON] label is the key. Sorry I forget to put this information in the = XML=20 schema. In the next version of the draft I will put it.

Does template refer to floors defined here?

[ON] templates should refer throught the 'label' attribute of the = data model=20 to the floors defined there.

8. Section 3.7 What if the conferencing system does not support=20 <join-handling> on a per-user setting, how is it conveyed?

[ON] <join-handling> is not a mandatory element. If the = conferencing=20 system does not support the <join-handling> element, the data = model of=20 this conferencing system does not have to define this element.

What if only a subset of joining methods is supported by the system = (how=20 would the client know what to choose from the UI)?

[ON] Then, the data model only would define the methods it supports. = It is=20 out of the scope of this draft to define how to do this. This = information should=20 be defined in the "conference control protocol" draft.

Would an organizer have to try all possible choices before choosing = the one=20 that is supported for a given user?

[ON] No, the organizer has to define the action if the user does not = support=20 this action, the user can not join the conference.

What about extensibility here? Same applies to other lists and = features.

[ON] The extensibility of this list or other lists in the model is = defined in=20 Section 5 of the document.

9. Section 3.7 Make <users-must-be-specified> explicitly fall = under an=20 admission-policy element.

[ON] the child element <users-must-be-specified> is closed = related with=20 the <dial-in-list> defined in the same element. Still it's = important to=20 keep both of them together.

Also, the schema does not appear to define
 this element. = Rename to=20 something more meaningful: like 'closedAuthenticated' when users must be = specified (and authenticated)
 and 'openAuthenticated' when = users can=20 be added after conference = activation.
 
    =20 <xs:element=20 name=3D"admission-policy"
 type=3D"tns:admission-policy-type"/>= ;
 
    =20 <xs:simpleType=20 name=3D"admission-policy-type">
      = ;  =20 <xs:restriction=20 base=3D"xs:string">
        = ;    =20 <xs:enumeration=20 value=3D"closedAuthenticated"/>
      = ;      =20 <xs:enumeration=20 value=3D"openAuthenticated"/>
      &= nbsp;     =20 <xs:enumeration=20 value=3D"anonymous"/>
       &nb= sp;=20 </xs:restriction>
     = </xs:simpleType>

[ON] I have changed the <users-must-be-specified> element for = the one=20 you said here.

10. Section 3.7.1.1 Can we cut <external> for the first version = of the=20 model? This can be achieved through simpler operations without = complicating the=20 data model itself 

[ON] When XCOn defines this operations that you mention we will cut = it from=20 the data model.

11. Section 3.7.2 What does a domain mean in the = <dial-out-list>? (How=20 do you enumerate the entities to dial out to?) 

[ON] Yes, true. I will remove it from the next version.

12. Section 3.7.2 Why differentiate between <dial-out-list> and = <refer-list>? It's clear that the Focus will act differently, just = don't=20 see the need to explicitly control this difference in behavior. This = seems more=20 reasonable to leave up to the implementation.

[ON] For a matter of clarity.

13. Section 3.7.2 <dial-out-list>, <dial-in-list> and=20 <refer-list> can be restructured and combined into one list. That = is, have=20 a list with all users in it and then enlist allowed joining-method's = referencing=20 the available or supported joining-methods in the conferencing system. = Make it=20 extensible to support an 'auto' joining method to accomplish previous = comment in=20 (12).

[ON] previous comment in (12)

14. Section 3.7.4 The <privileges-control-list> seems too = generic to be=20 implemented in a reasonably interoperable fashion. It also seems to = bloat the=20 data model.

[ON] I would be glad to read new ideas about the specification of = this=20 element in the data model. I know that this solution is not the best one = but, at=20 least, works.

Also, the conditions are ambiguous in several cases. For example,=20 <participant-passcode> (section 3.7.4.2.1.10) may be meaningless = in many=20 conferences.
How would this condition be interpreted in a conference = that=20 has no notion of passcodes?

[ON] If the conference system does not have any notion of passcode, = it will=20 not have this rule in its data model.

15. Section 3.7.5 The <authorization-mechanism> element is too = limiting=20 ...Digest/Digest-AKA do not even begin to scratch the surface of = possibilities.=20 Perhaps more importantly, there is no use-case for this being in the = data model=20 at all as it may be derived from other elements like = <join-handling>=20 and/or <admission-policy>.

[ON] I have removed this element from the data model.

16. There are several elements in the document that may require = role-based=20 definitions. For example, take <service-uris>. An organizer may = want one=20 set of service uri entries for presenters, but a
*different* set of = entries=20 for attendees. Similarly, in some cases, one may want to display = different=20 display-text based on whether the user is a presenter or the user is an=20 attendee. How would one achieve that?

[ON] I guess that we could use the <conference-rules> element = in the=20 example that you mention.


17. Minor XML schema point: when defining XML elements and their = types in=20 schema, it's generally better to use the full name followed by a "-type" = to=20 remain consistent. In the schema definition for the data model, this has = inconsistently been followed. For example:

         <xs:element=20 name=3D"maximum-user-count"
       =     =20 type=3D"maximum-user-type" minOccurs=3D"0"/>

 and elsewhere as

           = <xs:element=20 name=3D"conference-description"
      &n= bsp;    =20 type=3D"conference-description-type" minOccurs=3D"1"/>

[ON] thanks, I have fixed that typo.


Srivatsa

------_=_NextPart_001_01C69520.B60B9AC6-- --===============0136999644== 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 --===============0136999644==-- From xcon-bounces@ietf.org Wed Jun 21 18:05:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtApQ-00086x-UO; Wed, 21 Jun 2006 18:05:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtApP-00086s-Rx for xcon@ietf.org; Wed, 21 Jun 2006 18:05:39 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtApO-0003J2-GE for xcon@ietf.org; Wed, 21 Jun 2006 18:05:39 -0400 Received: from [127.0.0.1] ([172.17.2.251]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k5LM4MQs006928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 21 Jun 2006 17:04:23 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <4499C263.1030501@estacado.net> Date: Wed, 21 Jun 2006 17:04:19 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: xcon@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [XCON] XCON Pre-meeting Editing Session in Montreal 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 After much consideration of the current state of the working group, the chairs have determined that the best way to move forward is to obtain some form of consensus on a carefully reviewed data model. Discussion on protocol design is suspended and will resume once the data model has completed working group last call. Additionally, at this point, we are attempting to keep the XCON model as simple as possible; prior efforts to include various kitchen sinks in the model have caused the process to stall. In an effort to have the best chance of making productive use of our meeting time in Montreal, we propose a editing session on Sunday, July 9th, starting at Noon. This editing session will focus on the data model. We will use the scenarios document [1] and the current data model document [2] as input. As output, we intend to produce an internet-draft -- a -01 version of the data model document -- that can be discussed at the XCON meeting later in the week. Participants will be expected to write significant quantities of text, and should already be familiar with the framework [3] and existing data model. Please do not plan to show up if you haven't done the research necessary to participate. The plan is to: * Using only the information in the scenarios document, determine the minimum set of information that the data model must contain. Data that is not directly motivated by the scenarios document will not be considered for inclusion. * After isolating such elements, propose a potential structure for the data that makes sense. * Craft concrete text that describes how templates interact with the data model. This text may end up in the data model document, as amendments to the framework document, or split between the two. If you intend to participate: 1. Inform the chairs via e-mail. This is the only way to find out where the meeting will be. 2. Prior to getting off the plane in Montreal, you must have created your own list (in no particular order) of what you believe a minimum set of data is for the data model. Any data in your list must relate to one or more specific scenarios in the scenarios document. /a [1] http://www.ietf.org/internet-drafts/draft-ietf-xcon-conference-scenarios-05.txt [2] http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-00.txt [3] http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-03.txt _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Fri Jun 23 15:50:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftrfh-00030I-AN; Fri, 23 Jun 2006 15:50:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtrfH-0002LR-Dw; Fri, 23 Jun 2006 15:50:03 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtrfG-0004um-C3; Fri, 23 Jun 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5NJo1Rx021909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtrfF-0003Aa-Rh; Fri, 23 Jun 2006 15: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: Fri, 23 Jun 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-framework-04.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 and Data Model for Centralized Conferencing Author(s) : M. Barnes, et al. Filename : draft-ietf-xcon-framework-04.txt Pages : 57 Date : 2006-6-23 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 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-04.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-04.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-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-23124041.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-framework-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-framework-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-23124041.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon --NextPart-- From xcon-bounces@ietf.org Fri Jun 23 22:00:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtxRR-0002Oc-G3; Fri, 23 Jun 2006 22:00:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtxRN-0002MD-D3; Fri, 23 Jun 2006 22:00:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtsNl-0002EM-W9; Fri, 23 Jun 2006 16:36:02 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtrjD-0007mB-Tm; Fri, 23 Jun 2006 15:54:13 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5NJo2mU014807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtrfG-0003C2-GX; Fri, 23 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 23 Jun 2006 15:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-bfcp-connection-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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : Connection Establishment in the Binary Floor Control Protocol (BFCP) Author(s) : G. Camarillo Filename : draft-ietf-xcon-bfcp-connection-01.txt Pages : 14 Date : 2006-6-23 This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. This document also specifies a digest authentication mechanism for BFCP based on shared secrets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-bfcp-connection-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-ietf-xcon-bfcp-connection-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-ietf-xcon-bfcp-connection-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-23144556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-bfcp-connection-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-bfcp-connection-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-23144556.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 Tue Jun 27 05:36:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv9ze-0002wB-As; Tue, 27 Jun 2006 05:36:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv9zd-0002s4-BD for xcon@ietf.org; Tue, 27 Jun 2006 05:36:25 -0400 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv9za-00016t-Kz for xcon@ietf.org; Tue, 27 Jun 2006 05:36:25 -0400 Received: from GBNEWP0758M.eu.ubiquity.net ([62.172.205.164]) by rly23b.srv.mailcontrol.com (MailControl) with ESMTP id k5R9HJoU030891 for ; Tue, 27 Jun 2006 10:17:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Jun 2006 10:17:18 +0100 Message-ID: <45730E094814E44488F789C1CDED27AE04E78F22@gbnewp0758m.eu.ubiquity.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-boulton-sip-control-framework-03 Thread-Index: AcaZymk/7d/YTJRAS/ekRU64Sh/qmQAAAZyg From: "Chris Boulton" To: "XCON-IETF" X-Scanned-By: MailControl A-07-00-10 (www.mailcontrol.com) on 10.66.0.133 X-Spam-Score: 1.1 (+) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Subject: [XCON] FW: draft-boulton-sip-control-framework-03 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1053736868==" Errors-To: xcon-bounces@ietf.org This is a multi-part message in MIME format. --===============1053736868== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C699CA.7D37E20E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C699CA.7D37E20E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI =20 =20 -----Original Message----- From: Chris Boulton=20 Sent: 27 June 2006 10:17 To: mediactrl@lists.ubiquitysoftware.com Cc: 'Burger, Eric'; 'McGlashan, Scott'; 'Tim Melanchuk'; 'Asher Shiratzky' Subject: draft-boulton-sip-control-framework-03 =20 A new version of the Control Framework has been submitted. Until it appears in the archives, you can get a copy from http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework -03.txt and http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-control-framework -03.html. =20 Not really a major revision - just some small changes and clarifications based on feedback received. Primary change is the inclusion of a fixed 'SCFW' token at the start of a framework message for ease of access to the transaction identifier when parsing. =20 Best Regards, =20 Chris. =20 Information contained in this e-mail and any attachments are intended for t= he use of the addressee only, and may contain confidential information of U= biquity Software Corporation. All unauthorized use, disclosure or distribu= tion is strictly prohibited. If you are not the addressee, please notify t= he sender immediately and destroy all copies of this email. Unless otherwi= se expressly agreed in writing signed by an officer of Ubiquity Software Co= rporation, nothing in this communication shall be deemed to be legally bind= ing. Thank you. ------_=_NextPart_001_01C699CA.7D37E20E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI

 

 

-----Original Message-----
From: Chris Boulton
Sent: 27= June 2006= 10:17=
To: mediactrl@lists.ubiquitysoftware.com
Cc: 'Burger, Eric'; 'McGlash= an, Scott'; 'Tim Melanchuk'; 'Asher Shiratzky'
Subject: draft-boulton-sip-control-framework-03

 

A new version of the Control Framework has been submitted.  Until it appears in the archives, you can get a copy from = http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-contro= l-framework-03.txt and http://www.ubiquitysoftware.com/ietf/draft-boulton-sip-contr= ol-framework-03.html.

 

Not really a major revision – just some sma= ll changes and clarifications based on feedback received.  Primary change= is the inclusion of a fixed ‘SCFW’ token at the start of a framewo= rk message for ease of access to the transaction identifier when parsing.

 

Best Regards,

 

Chris.

 



Information contained in t= his e-mail and any attachments are intended for the use of the addressee on= ly, and may contain confidential information of Ubiquity Software Corporati= on. All unauthorized use, disclosure or distribution is strictly prohibited= .  If you are not the addressee, please notify the sender immediately = and destroy all copies of this email.  Unless otherwise expressly agre= ed in writing signed by an officer of Ubiquity Software Corporation, nothin= g in this communication shall be deemed to be legally binding. Thank-you ------_=_NextPart_001_01C699CA.7D37E20E-- --===============1053736868== 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 --===============1053736868==-- From xcon-bounces@ietf.org Tue Jun 27 19:44:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvNEX-0001vB-8Q; Tue, 27 Jun 2006 19:44:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvNEV-0001tK-LN; Tue, 27 Jun 2006 19:44:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvMWT-0006PC-S3; Tue, 27 Jun 2006 18:59:09 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvMOe-0007NT-GL; Tue, 27 Jun 2006 18:51:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5RMo2jx020065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Jun 2006 22:50:04 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FvMNe-0005sm-4l; Tue, 27 Jun 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 27 Jun 2006 18:50:02 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: xcon@ietf.org Subject: [XCON] I-D ACTION:draft-ietf-xcon-common-data-model-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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Centralized Conferencing Working Group of the IETF. Title : A Common Conference Information Data Model for Centralized Conferencing (XCON) Author(s) : O. Novo, et al. Filename : draft-ietf-xcon-common-data-model-01.txt Pages : 54 Date : 2006-6-27 This document collects, organizes, and describes the conference variables that have been introduced in various protocol drafts of the XCON and SIPPING working groups. The goal of this document is to allow the conference control protocols to use a unified common conference information data model for XCON. This document formally defines an Extensible Markup Language (XML) Schema that represents the common conference information in a conferencing server. The information is modeled as a series of elements, each of which contains a set of children and attributes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-xcon-common-data-model-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-ietf-xcon-common-data-model-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-ietf-xcon-common-data-model-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-27165348.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-xcon-common-data-model-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-xcon-common-data-model-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-27165348.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 Jun 28 18:09:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FviE3-0000T8-IC; Wed, 28 Jun 2006 18:09:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FviE1-0000T3-QL for xcon@ietf.org; Wed, 28 Jun 2006 18:09:33 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FviE0-0003zT-Fq for xcon@ietf.org; Wed, 28 Jun 2006 18:09:33 -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 k5SM9UT28822 for ; Wed, 28 Jun 2006 18:09:30 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Jun 2006 17:09:29 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Changes to -04 version of XCON Framework Thread-Index: Acaa/4b7rEl6HVcoQcq6lwZ/WZTRqQ== From: "Mary Barnes" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [XCON] Changes to -04 version of XCON Framework 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 Just in case you missed the announcement, there is an updated version of the framework available: http://www.ietf.org/internet-drafts/draft-ietf-xcon-framework-04.txt The following summarizes the changes based on Sean Olson's comments at IETF-65 and Dave Morgan's detailed review prior. The changes are also summarized towards the end of the document.=20 1. Various editorial nits and clarifications. 2. In section 4 (Terminology), for the definition of "Conference Template", removed the text "and/or user interface abstractions"=20 3. In section 5.2 (Conferencing Template), first paragraph, removed the text "and to allow for easy user interface abstraction" 4. Section 5.2, removed the fourth paragraph: A conference template can also include an abstract user interface definition in terms of sliders, radio boxes, etc. for simplifying user interaction with a specific non-trivial feature. 5. Expanded examples in section 9.6 (Conference Announcements and Recordings) 6. Added two new sections 9.7 (DTMF) and 9.8 (Observing a Conference), with some initial text.=20 Feedback would primarily be useful on the new sections, as I think there has been sufficient detailed review of the other sections. Once the WG decides the protocol direction, some content can be removed and other content modified. There are still appendices defining the identifiers - we'll need to pull that information into separate docs at some point.=20 Regards, Mary _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon From xcon-bounces@ietf.org Thu Jun 29 16:05:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2lS-0006pg-7D; Thu, 29 Jun 2006 16:05:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2io-00049s-6k for xcon@ietf.org; Thu, 29 Jun 2006 16:02:42 -0400 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw2im-0004EC-VS for xcon@ietf.org; Thu, 29 Jun 2006 16:02:42 -0400 Received: from [64.80.16.230] (helo=[192.168.0.246]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1Fw2im-000Nw0-J9; Thu, 29 Jun 2006 16:02:40 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 64.80.16.230 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <44A431DD.2030800@sipstation.com> Date: Thu, 29 Jun 2006 15:02:37 -0500 From: Alan Johnston User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xcon@ietf.org, Adam Roach Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [XCON] Agenda Requests for IETF-66 X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xcon-bounces@ietf.org All, Please email agenda requests to Adam and myself as the agenda needs to be finalized by Monday July 3. Request should include the name of the draft and the requested amount of time. Thanks, Alan Johnston co-chair XCON _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon