idnits 2.17.1 

draft-ietf-clue-protocol-02.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There are 142 instances of too long lines in the document, the longest
     one being 10 characters in excess of 72.

  ** The abstract seems to contain references ([I-D.ietf-clue-signaling],
     [I-D.ietf-clue-framework], [I-D.ietf-clue-datachannel],
     [I-D.ietf-clue-telepresence-requirements]), which it shouldn't.  Please
     replace those with straight textual mentions of the documents in question.

  ** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
     keywords. 

     RFC 2119 keyword, line 217: '...a CLUE dialogue, the involved CPs MUST...'
     RFC 2119 keyword, line 404: '...   SHOULD be provided for each major v...'
     RFC 2119 keyword, line 413: '...   <version> tag MUST be included....'
     RFC 2119 keyword, line 436: '...o errors, the CR MUST insert within th...'
     RFC 2119 keyword, line 439: '...ent of the <version> element MUST be a...'
     (5 more instances...)


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).
     
     Found 'SHOULD not' in this paragraph:
     
     The optional boolean <ack> element, set to "true", if present,
     indicates that the CONF message also acknowledge the referred
     advertisement, by applying in that way a piggibacking mechanism for
     simultaneously acknowledging and replying to the ADV message.  The <ack>
     element SHOULD not be present at all if an ADV ACK message has been
     already sent back to the MP.

  -- The document date (October 24, 2014) is 3473 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Unused Reference: 'RFC6502' is defined on line 2592, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC6503' is defined on line 2600, but no explicit
     reference was found in the text

  == Outdated reference: A later version (-17) exists of
     draft-ietf-clue-data-model-schema-07

  ** Downref: Normative reference to an Experimental draft:
     draft-ietf-clue-datachannel (ref. 'I-D.ietf-clue-datachannel')

  == Outdated reference: A later version (-25) exists of
     draft-ietf-clue-framework-17

  == Outdated reference: A later version (-15) exists of
     draft-ietf-clue-signaling-03

  ** Downref: Normative reference to an Experimental draft:
     draft-ietf-clue-signaling (ref. 'I-D.ietf-clue-signaling')

  ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303)

  ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)

  -- Obsolete informational reference (is this intentional?): RFC 5117
     (Obsoleted by RFC 7667)


     Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

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


2	CLUE Working Group                                             R. Presta
3	Internet-Draft                                                 S. Romano
4	Intended status: Standards Track                    University of Napoli
5	Expires: April 27, 2015                                 October 24, 2014

7	                             CLUE protocol
8	                      draft-ietf-clue-protocol-02

10	Abstract

12	   The CLUE protocol is an application protocol conceived for the
13	   description and negotiation of a CLUE telepresence session.  The
14	   design of the CLUE protocol takes into account the requirements and
15	   the framework defined, respectively, in [I-D.ietf-clue-framework] and
16	   [I-D.ietf-clue-telepresence-requirements].  The companion document
17	   [I-D.ietf-clue-signaling] delves into CLUE signaling details, as well
18	   as on the SIP/SDP session establishment phase.  CLUE messages flow
19	   upon the CLUE data channel, based on reliable and ordered SCTP over
20	   DTLS transport, as described in [I-D.ietf-clue-datachannel].  Message
21	   details, together with the behavior of CLUE Participants acting as
22	   Media Providers and/or Media Consumers, are herein discussed.

24	Status of This Memo

26	   This Internet-Draft is submitted in full conformance with the
27	   provisions of BCP 78 and BCP 79.

29	   Internet-Drafts are working documents of the Internet Engineering
30	   Task Force (IETF).  Note that other groups may also distribute
31	   working documents as Internet-Drafts.  The list of current Internet-
32	   Drafts is at http://datatracker.ietf.org/drafts/current/.

34	   Internet-Drafts are draft documents valid for a maximum of six months
35	   and may be updated, replaced, or obsoleted by other documents at any
36	   time.  It is inappropriate to use Internet-Drafts as reference
37	   material or to cite them other than as "work in progress."

39	   This Internet-Draft will expire on April 27, 2015.

41	Copyright Notice

43	   Copyright (c) 2014 IETF Trust and the persons identified as the
44	   document authors.  All rights reserved.

46	   This document is subject to BCP 78 and the IETF Trust's Legal
47	   Provisions Relating to IETF Documents
48	   (http://trustee.ietf.org/license-info) in effect on the date of
49	   publication of this document.  Please review these documents
50	   carefully, as they describe your rights and restrictions with respect
51	   to this document.  Code Components extracted from this document must
52	   include Simplified BSD License text as described in Section 4.e of
53	   the Trust Legal Provisions and are provided without warranty as
54	   described in the Simplified BSD License.

56	Table of Contents

58	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
59	   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
60	   3.  Overview of the CLUE protocol  . . . . . . . . . . . . . . . .  5
61	   4.  Protocol messages  . . . . . . . . . . . . . . . . . . . . . .  7
62	     4.1.  OPTIONS  . . . . . . . . . . . . . . . . . . . . . . . . .  9
63	     4.2.  OPTIONS RESPONSE . . . . . . . . . . . . . . . . . . . . . 11
64	     4.3.  ADVERTISEMENT  . . . . . . . . . . . . . . . . . . . . . . 12
65	     4.4.  ADVERTISEMENT ACKNOWLEDGEMENT  . . . . . . . . . . . . . . 14
66	     4.5.  CONFIGURE  . . . . . . . . . . . . . . . . . . . . . . . . 15
67	     4.6.  CONFIGURE RESPONSE . . . . . . . . . . . . . . . . . . . . 16
68	     4.7.  Response codes and reason strings  . . . . . . . . . . . . 16
69	   5.  Protocol state machines  . . . . . . . . . . . . . . . . . . . 18
70	   6.  CLUE Participant's state machine . . . . . . . . . . . . . . . 18
71	     6.1.  Media Provider's state machine . . . . . . . . . . . . . . 21
72	     6.2.  Media Consumer's state machine . . . . . . . . . . . . . . 24
73	   7.  Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . 26
74	   8.  Extensions and options . . . . . . . . . . . . . . . . . . . . 27
75	   9.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 29
76	   10. ADVERTISEMENT examples . . . . . . . . . . . . . . . . . . . . 34
77	     10.1. Simple ADV . . . . . . . . . . . . . . . . . . . . . . . . 34
78	     10.2. ADV with MCCs  . . . . . . . . . . . . . . . . . . . . . . 40
79	     10.3. Partial ADV  . . . . . . . . . . . . . . . . . . . . . . . 47
80	   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 51
81	     11.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 51
82	     11.2. XML Schema registration  . . . . . . . . . . . . . . . . . 52
83	     11.3. MIME Media Type Registration for 'application/clue+xml'  . 52
84	     11.4. DNS Registrations  . . . . . . . . . . . . . . . . . . . . 53
85	       11.4.1.  Application Service tag . . . . . . . . . . . . . . . 53
86	       11.4.2.  Application Protocol tag  . . . . . . . . . . . . . . 54
87	     11.5. CLUE Protocol Registry . . . . . . . . . . . . . . . . . . 54
88	       11.5.1.  CLUE Message Types  . . . . . . . . . . . . . . . . . 54
89	       11.5.2.  CLUE Response Codes . . . . . . . . . . . . . . . . . 55
90	   12. Diff with draft-ietf-clue-protocol-01  . . . . . . . . . . . . 55
91	   13. Diff with draft-ietf-clue-protocol-00  . . . . . . . . . . . . 56
92	   14. Diff with draft-presta-clue-protocol-04  . . . . . . . . . . . 56
93	   15. Diff with draft-presta-clue-protocol-03  . . . . . . . . . . . 56
94	   16. Diff with draft-presta-clue-protocol-02  . . . . . . . . . . . 56
95	   17. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 57
96	   18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
97	     18.1. Normative References . . . . . . . . . . . . . . . . . . . 57
98	     18.2. Informative References . . . . . . . . . . . . . . . . . . 58

100	1.  Introduction

102	   The CLUE protocol is an application protocol used by two CLUE
103	   Participants to enhance the experience of a multimedia telepresence
104	   session.  The main goals of the CLUE protocol are:

106	   1.  enabling a MP to properly announce its current telepresence
107	       capabilities to a MC in terms of available media captures, groups
108	       of encodings, simultaneity constraints and other information
109	       envisioned in [I-D.ietf-clue-framework];

111	   2.  enabling a MC to request the desired multimedia streams to the
112	       offering MP.

114	   CLUE-capable endpoints are connected by means of the CLUE data
115	   channel, an SCTP over DTLS channel which is opened and established as
116	   depicted in [I-D.ietf-clue-signaling] and
117	   [I-D.ietf-clue-datachannel].  CLUE protocol messages flowing upon
118	   such a channel are detailed in this document, both syntactically and
119	   semantically.

121	   In Section 3 we provide a general overview of the CLUE protocol.
122	   CLUE protocol messages are detailed in Section 4 The CLUE Participant
123	   state machine is introduced in Section 5.  Versioning and extensions
124	   are discussed in Section 7 and Section 8, respectively.  The XML
125	   schema defining the CLUE messages is reported in Section 9.

127	2.  Terminology

129	   This document refers to the same terminology used in
130	   [I-D.ietf-clue-framework] and in
131	   [I-D.ietf-clue-telepresence-requirements].  We briefly recall herein
132	   some of the main terms used in the document.  The definition of "CLUE
133	   Participant" herein proposed is not imported from any of the above
134	   documents.

136	   CLUE Participant:  An entity able to use the CLUE protocol within a
137	      telepresence session.  It can be an endpoint or an MCU able to use
138	      the CLUE protocol.

140	   Endpoint:  The logical point of final termination through receiving,
141	      decoding and rendering, and/or initiation through capturing,
142	      encoding, and sending of media streams.  An endpoint consists of
143	      one or more physical devices which source and sink media streams,
144	      and exactly one [RFC4353] Participant (which, in turn, includes
145	      exactly one SIP User Agent).  Endpoints can be anything from
146	      multiscreen/multicamera room controllers to handheld devices.

148	   MCU:  Multipoint Control Unit (MCU) - a device that connects two or
149	      more endpoints together into one single multimedia conference
150	      [RFC5117].  An MCU may include a Mixer [RFC4353].

152	   Media:  Any data that, after suitable encoding, can be conveyed over
153	      RTP, including audio, video or timed text.

155	   Media Capture:  A "Media Capture", or simply "Capture", is a source
156	      of Media.

158	   Capture Encoding:  A specific encoding of a Media Capture, to be sent
159	      via RTP [RFC3550].

161	   Media Stream:  The term "Media Stream", or simply "Stream", is used
162	      as a synonymous of Capture Encoding.

164	   Media Provider:  A CLUE Participant (i.e., an Endpoint or an MCU)
165	      able to send Media Streams.

167	   Media Consumer:  A CLUE Participant (i.e., an Endpoint or an MCU)
168	      able to receive Media Streams.

170	3.  Overview of the CLUE protocol

172	   The CLUE protocol is conceived to enable CLUE telepresence sessions.
173	   It is designed in order to address SDP limitations in terms of the
174	   description of some information about the multimedia streams that are
175	   involved in a real-time multimedia conference.  Indeed, by simply
176	   using SDP we are not able to convey information about the features of
177	   the flowing multimedia streams that are needed to enable a "being
178	   there" rendering experience.  Such information is designed in the
179	   CLUE framework document and formally defined and described in the
180	   CLUE data model document.  The CLUE protocol represents the mechanism
181	   for the exchange of CLUE information between CLUE Participants.  It
182	   mainly provides the messages to enable a Media Provider to advertise
183	   its telepresence capabilities and to enable a Media Consumer to
184	   select the desired telepresence options.

186	   The CLUE protocol, as defined in the following, is a stateful,
187	   client-server, XML-based application protocol.  CLUE protocol
188	   messages flow on a realiable and ordered SCTP over DTLS transport
189	   channel connecting two CLUE Participants.  Messages carry information
190	   taken from the XML-based CLUE data model
191	   ([I-D.ietf-clue-data-model-schema]).  Three main communication layers
192	   can be identified:

194	   1.  Establishment of the CLUE data channel: in this phase, the CLUE
195	       data channel setup takes place.  If it completes successfully,
196	       the CPs are able to communicate and start the initiation phase.

198	   2.  Negotiation of the CLUE protocol version and options (initiation
199	       phase): the CPs connected via the CLUE data channel agree on the
200	       version and on the options to be used during the telepresence
201	       session.  Special CLUE messages are used for such a task.  At the
202	       end of that basic negotiation, each CP starts its activity as a
203	       CLUE MP and/or CLUE MC.

205	   3.  CLUE telepresence capabilities description and negotiation: in
206	       this phase, the MP-MC dialogues take place on the data channel by
207	       means of the CLUE protocol messages.

209	   As soon as the channel is ready, the CLUE Participants must agree on
210	   the protocol version and extensions to be used within the
211	   telepresence session.  CLUE protocol version numbers are
212	   characterized by a major version number and a minor version number,
213	   both unsigned integers, separated by a dot.  While minor version
214	   numbers denote backward compatible changes in the context of a given
215	   major version, different major version numbers generally indicate a
216	   lack of interoperability between the protocol implementations.  In
217	   order to correctly establish a CLUE dialogue, the involved CPs MUST
218	   have in common a major version number (see Section 7 for further
219	   details).  The subset of the protocol options and extensions that are
220	   allowed within the CLUE session is also determined in the initiation
221	   phase, such subset being the one including only the options that are
222	   supported by both parties.  A mechanism for the negotiation of the
223	   CLUE protocol version and extensions is envisioned in the initiation
224	   phase.  According to such a solution, the CP which is the CLUE
225	   Channel initiator (CI) issues a proper CLUE message (OPTIONS) to the
226	   CP which is the Channel Receiver (CR) specifying the supported
227	   version and extensions.  The CR then answers by selecting the subset
228	   of the CI extensions that it is able to support and determines the
229	   protocol version to be used.

231	   After that negotiation phase is completed, CLUE Participants describe
232	   and agree on the media flows to be exchanged.  Indeed, being CPs A
233	   and B both transmitting and receiving, it is possible to distinguish
234	   between two dialogues:

236	   1.  the one needed to describe and set up the media streams sent from
237	       A to B, i.e., the dialogue between A's Media Provider side and
238	       B's Media Consumer side

240	   2.  the one needed to describe and set up the media streams sent from
241	       B to A, i.e., the dialogue between B's Media Provider side and
242	       A's Media Consumer side

244	   CLUE messages for the media session description and negotiation are
245	   designed by considering the MP side as the server side of the
246	   protocol, since it produces and provides media streams, and the MC
247	   side as the client side of the protocol, since it requests and
248	   receives media streams.  The messages that are exchanged to set up
249	   the telepresence media session are described by focusing on a single
250	   MP-MC dialogue.

252	   The MP first advertises its available media captures and encoding
253	   capabilities to the MC, as well as its simultaneity constraints,
254	   according to the information model defined in
255	   [I-D.ietf-clue-framework].  The CLUE message conveying the MP's
256	   multimedia offer is the ADVERTISEMENT message.  Such message
257	   leverages the XML data model definitions provided in
258	   [I-D.ietf-clue-data-model-schema].

260	   The MC selects the desired streams of the MP by using the CONFIGURE
261	   message, which makes reference to the information carried in the
262	   previously received ADVERTISEMENT.

264	   Besides ADVERTISEMENT and CONFIGURE, other messages have been
265	   conceived in order to provide all the needed mechanisms and
266	   operations.  Such messages will be detailed in the following
267	   sections.

269	4.  Protocol messages

271	   CLUE protocol messages are textual, XML-based messages that enable
272	   the configuration of the telepresence session.  The formal definition
273	   of such messages is provided in the XML Schema provided at the end of
274	   this document (Section 9).

276	   The XML definitions of the CLUE information provided in
277	   [I-D.ietf-clue-data-model-schema] are included within some CLUE
278	   protocol messages (namely the ADVERTISEMENT and the CONFIGURE
279	   messages), in order to use the concepts defined in
280	   [I-D.ietf-clue-framework].

282	   The CLUE protocol messages are the following:

284	   o  OPTIONS

286	   o  OPTIONS RESPONSE

288	   o  ADVERTISEMENT (ADV)

290	   o  ADVERTISEMENT ACKNOWLEDGEMENT (ACK)
291	   o  CONFIGURE (CONF)

293	   o  CONFIGURE RESPONSE

295	   While the OPTIONS and OPTIONS RESPONSE messages are exchanged in the
296	   initiation phase between the CPs, the other messages are involved in
297	   MP-MC dialogues.

299	   Each CLUE message inherits a basic structure depicted in the
300	   following excerpt:

302	<!-- CLUE MESSAGE TYPE -->
303	<xs:complexType name="clueMessageType" abstract="true">
304	<xs:sequence>
305	<xs:element name="clueId" type="xs:string"/>
306	<xs:element name="sequenceNr" type="xs:unsignedInt"/>
307	</xs:sequence>
308	<xs:attribute name="protocol" type="xs:string" fixed="CLUE" use="required"/>
309	<xs:attribute name="v" type="xs:string" use="required"/>
310	</xs:complexType>

312	   The basic structure determines the mandatory information that is
313	   carried within each CLUE message.  Such an information is made by:

315	   o  clueId: an XML element containing the identifier of the CP within
316	      the telepresence system;

318	   o  sequenceNr: an XML element containing the local message sequence
319	      number;

321	   o  protocol: a mandatory attribute set to "CLUE", identifying the
322	      procotol the messages refer to;

324	   o  v: a mandatory attribute carrying the version of the protocol.
325	      The content of the "v" attribute is composed by the major version
326	      number followed by a dot and then by the minor version number of
327	      the CLUE protocol in use.  Allowed values are of this kind: "1.3",
328	      "2.45", etc.

330	   Each CP should manage up to three streams of sequence numbers: (i)
331	   one for the messages exchanged in the initiation phase, (ii) one for
332	   the messages exchanged as MP, and (iii) one for the messages
333	   exchanged as MC.

335	4.1.  OPTIONS

337	   The OPTIONS message is sent by the CP which is the CI to the CP which
338	   is the CR as soon as the CLUE data channel is ready.  Besides the
339	   information envisioned in the basic structure, it specifies:

341	   o  mediaProvider: a mandatory boolean field set to "true" if the CP
342	      is able to act as a MP

344	   o  mediaConsumer: a mandatory boolean field set to "true" if the CP
345	      is able to act as a MC

347	   o  supportedVersions: the list of the supported versions

349	   o  supportedOptions: the list of the supported options

351	   The XML Schema of such a message is reported below:

353	<!-- CLUE OPTIONS -->
354	<xs:complexType name="optionsMessageType">
355	<xs:complexContent>
356	<xs:extension base="clueMessageType">
357	<xs:sequence>
358	<xs:element name="mediaProvider" type="xs:boolean"/>
359	<xs:element name="mediaConsumer" type="xs:boolean"/>
360	<xs:element name="supportedVersions" type="versionsListType" minOccurs="0"/>
361	<xs:element name="supportedOptions" type="optionsListType" minOccurs="0"/>
362	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
363	</xs:sequence>
364	<xs:anyAttribute namespace="##other" processContents="lax"/>
365	</xs:extension>
366	</xs:complexContent>
367	</xs:complexType>

369	<!-- VERSIONS LIST TYPE -->
370	<xs:complexType name="versionsListType">
371	<xs:sequence>
372	<xs:element name="version" type="xs:string" minOccurs="1"
373	 maxOccurs="unbounded"/>
374	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
375	</xs:sequence>
376	<xs:anyAttribute namespace="##other" processContents="lax"/>
377	</xs:complexType>

379	<!-- OPTIONS LIST TYPE -->
380	<xs:complexType name="optionsListType">
381	<xs:sequence>
382	<xs:element name="option" type="optionType" minOccurs="1"
383	 maxOccurs="unbounded"/>
384	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
385	</xs:sequence>
386	<xs:anyAttribute namespace="##other" processContents="lax"/>
387	</xs:complexType>

389	<!-- OPTION TYPE -->
390	<xs:complexType name="optionType">
391	<xs:sequence>
392	<xs:element name="name" type="xs:string" />
393	<xs:element name="schemaRef" type="xs:anyURI" minOccurs="0"/>
394	<xs:element name="version" type="xs:string" minOccurs="0"/>
395	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
396	</xs:sequence>
397	<xs:anyAttribute namespace="##other" processContents="lax"/>
398	</xs:complexType>
399	   <supportedVersions> contains the list of the versions that are
400	   supported by the CI, each one represented in a child <version>
401	   element.  The content of each <version> element is a string made by
402	   the major version number followed by a dot and then by the minor
403	   version number (e.g., 1.3 or 2.43).  Only one <version> element
404	   SHOULD be provided for each major version supported, containing the
405	   maximum minor version number of such a version, since all minor
406	   versions are backward compatible.  If no <supportedVersions> is
407	   carried whithin the OPTIONS message, the CI supports only the version
408	   declared in the "v" attribute.  For example, if the "v" attribute has
409	   a value of "3.4" and there is no <supportedVersions> tag in the
410	   OPTIONS message, it means the CI supports only major version 3 with
411	   all the minor versions comprised between 3.0 and 3.4, with version
412	   3.4 included.  If a <supportedVersion> is provided, at least one
413	   <version> tag MUST be included.

415	   The <supportedOptions> element specifies the list of options
416	   supported by the CI.  If there is no <supportedOptions> in the
417	   OPTIONS message, the CI does not support anything other than what is
418	   envisioned in the versions it supports.  For each option, an <option>
419	   element is provided.  An option is characterized by a name, an XML
420	   schema of reference where the option is defined, and the version of
421	   the protocol which the option refers to.  [Editors' note: to be
422	   discussed: difference between options and extensions]

424	4.2.  OPTIONS RESPONSE

426	   The OPTIONS RESPONSE is sent by a CR to a CI as a reply to the
427	   OPTIONS message.  As depicted in the figure below, the OPTIONS
428	   RESPONSE contains mandatorily a response code and a response string
429	   indicating the processing result of the OPTIONS message.  Following,
430	   the CR attaches two boolean tags, <mediaProvider> and
431	   <mediaConsumer>, expressing the supported roles in terms of
432	   respectively MP and MC, similarly to what the CI does in the OPTIONS
433	   message.  These two elements are optional in the OPTIONS RESPONSE
434	   since, in case of error response code, the CR might not want to add
435	   further information besides the response code and the reason string.
436	   In case of no errors, the CR MUST insert within the OPTIONS RESPONSE
437	   the <mediaProvider> and the <mediaConsumer> elements.  Finally, the
438	   highest commonly supported version number is expressed in the
439	   <version> field.  The content of the <version> element MUST be a
440	   string made by the major version number followed by a dot and then by
441	   the minor version number (e.g., 1.3 or 2.43).  The commonly supported
442	   options are copied in the the <commonOptions> field.

444	 <!-- CLUE OPTIONS RESPONSE -->
445	 <xs:complexType name="optionsResponseMessageType">
446	 <xs:complexContent>
447	 <xs:extension base="clueMessageType">
448	 <xs:sequence>
449	 <xs:element name="responseCode" type="xs:short"/>
450	 <xs:element name="reasonString" type="xs:string"/>
451	 <xs:element name="mediaProvider" type="xs:boolean" minOccurs="0"/>
452	 <xs:element name="mediaConsumer" type="xs:boolean" minOccurs="0"/>
453	 <xs:element name="version" type="xs:string" minOccurs="0"/>
454	 <xs:element name="commonOptions" type="optionsListType" minOccurs="0"/>
455	 <xs:any namespace="##other"
456	 processContents="lax" minOccurs="0"/>
457	 </xs:sequence>
458	 <xs:anyAttribute namespace="##other" processContents="lax"/>
459	 </xs:extension>
460	 </xs:complexContent>
461	 </xs:complexType>

463	   After the reception of such a message, the version to be used is
464	   determined by each part of the conversation.  Indeed, it is the one
465	   provided in the <version> tag of the OPTIONS RESPONSE message.  The
466	   following CLUE messages will use such a version number in the "v"
467	   attribute.  The allowed options in the CLUE dialogue will be those
468	   indicated in the <commonOptions> of the OPTIONS RESPONSE message.

470	4.3.  ADVERTISEMENT

472	   This message is used by the MP to advertise the available media
473	   captures and related information to the MC.  The MP sends to the MC
474	   an ADV as soon as it is ready after the successful completion of the
475	   initiation phase, i.e., as soon as the version and the options of the
476	   CLUE protocol are agreed between the CPs.  During the telepresence
477	   session, the ADV can be sent from the MP both periodically and on a
478	   per-event basis, i.e., each time there are changes in the MP's CLUE
479	   telepresence capabilities.

481	   The ADV structure is defined in the picture below.  The ADV contains
482	   elements compliant with the CLUE data model that characterize the
483	   MP's telepresence offer.  Namely, such elements are: the list of the
484	   media captures (<mediaCaptures>), of the encoding groups
485	   (<encodingGroups>), of the capture scenes (<captureScenes>) of the
486	   global views (<globalViews>), and of the represented participants
487	   (<people>).  Each of them is fully described in the CLUE framework
488	   document and formally defined in the CLUE data model document.

490	   When an ADV sent from the MP to the MC has been ACK-ed by the MC, the
491	   MP can decide to send the next ADV in a diff format with respect to
492	   the previously sent ADV.  The diff format is expressed according to
493	   [RFC5261] and has been analysed in [I-D.groves-clue-partial-update]
494	   as a convenient shortcut to communicate the update in the MP's
495	   telepresence capabilities.  When using such shortcut, the ADV body is
496	   made by a sequence of (i) <add>, (ii) <remove>, and (iii) <replace>
497	   elements, each of them associated with an XPath selector indicating
498	   respectively (i) the place where to add the data model information
499	   carried in the considered <add> element, (ii) the element to be
500	   removed, (iii) the element to be replaced with the content carried
501	   within the considered <replace> element.  An example of the diff
502	   mechanism is shown in Section Examples.

504	   <!-- CLUE ADVERTISEMENT MESSAGE TYPE -->
505	   <xs:complexType name="advertisementMessageType">
506	   <xs:complexContent>
507	   <xs:extension base="clueMessageType">
508	   <xs:choice>
509	   <!-- full adv body -->
510	   <xs:sequence>
511	           <!-- mandatory fields -->
512	           <xs:element name="mediaCaptures" type="dm:mediaCapturesType"/>
513	           <xs:element name="encodingGroups" type="dm:encodingGroupsType"/>
514	           <xs:element name="captureScenes" type="dm:captureScenesType"/>
515	           <!-- optional fields -->
516	           <xs:element name="simultaneousSets" type="dm:simultaneousSetsType"
517	            minOccurs="0"/>
518	           <xs:element name="globalViews" type="dm:globalViewsType"
519	            minOccurs="0"/>
520	           <xs:element name="people" type="dm:peopleType" minOccurs="0"/>
521	           <xs:any namespace="##other" processContents="lax" minOccurs="0"/>
522	   </xs:sequence>
523	   <!-- partial adv body -->
524	   <xs:sequence minOccurs="0" maxOccurs="unbounded">
525	    <xs:choice>
526	     <!-- add some content -->
527	     <xs:element name="add">
528	      <xs:complexType mixed="true">
529	       <xs:complexContent>
530	        <xs:extension base="add">
531	         <xs:anyAttribute processContents="lax"/>
532	        </xs:extension>
533	       </xs:complexContent>
534	      </xs:complexType>
535	     </xs:element>
536	     <!-- remove some content -->
537	     <xs:element name="remove">
538	      <xs:complexType>
539	       <xs:complexContent>
540	        <xs:extension base="remove">
541	         <xs:anyAttribute processContents="lax"/>
542	        </xs:extension>
543	       </xs:complexContent>
544	      </xs:complexType>
545	     </xs:element>
546	     <!-- replace some content -->
547	     <xs:element name="replace">
548	      <xs:complexType mixed="true">
549	       <xs:complexContent>
550	        <xs:extension base="replace">
551	         <xs:anyAttribute processContents="lax"/>
552	        </xs:extension>
553	       </xs:complexContent>
554	      </xs:complexType>
555	     </xs:element>
556	     <!-- allow extension elements from other namespaces -->
557	     <xs:any namespace="##other" processContents="lax"/>
558	      </xs:choice>
559	   </xs:sequence>
560	   </xs:choice>
561	   <xs:anyAttribute namespace="##other" processContents="lax"/>
562	   </xs:extension>
563	   </xs:complexContent>
564	   </xs:complexType>

566	4.4.  ADVERTISEMENT ACKNOWLEDGEMENT

568	   The ACK message is sent by a MC to a MP to acknowledge an ADV
569	   message.  As it can be seen from the message schema provided in the
570	   following, the ACK contains a response code and a reason string for
571	   describing the processing result of the ADV.  The <advSequenceNr>
572	   carries the sequence number of the ADV the ACK refers to.

574	   <!-- ADV ACK MESSAGE TYPE -->
575	   <xs:complexType name="advAcknowledgementMessageType">
576	   <xs:complexContent>
577	   <xs:extension base="clueMessageType">
578	   <xs:sequence>
579	   <xs:element name="responseCode" type="xs:short"/>
580	   <xs:element name="reasonString" type="xs:string"/>
581	   <xs:element name="advSequenceNr" type="xs:unsignedInt"/>
582	   <xs:any namespace="##other" processContents="lax" minOccurs="0"/>
583	   </xs:sequence>
584	   <xs:anyAttribute namespace="##other" processContents="lax"/>
585	   </xs:extension>
586	   </xs:complexContent>
587	   </xs:complexType>

589	4.5.  CONFIGURE

591	   The CLUE CONFIGURE message is sent from a MC to a MP to list the
592	   advertised captures the MC wants to receive.  The MC can send a CONF
593	   after the reception of an ADV or each time it wants to request other
594	   captures that have been previously advertised by the MP.  The content
595	   of the CONF message is shown below.

597	    <!-- CLUE CONFIGURE MESSAGE TYPE -->
598	   <xs:complexType name="configureMessageType">
599	   <xs:complexContent>
600	   <xs:extension base="clueMessageType">
601	   <xs:sequence>
602	   <!-- mandatory fields -->
603	   <xs:element name="advSequenceNr" type="xs:unsignedInt"/>
604	   <xs:element name="ack" type="xs:boolean" minOccurs="0" fixed="true"/>
605	   <xs:element name="captureEncodings" type="dm:captureEncodingsType"
606	    minOccurs="0"/>
607	   <xs:any namespace="##other" processContents="lax" minOccurs="0"/>
608	   </xs:sequence>
609	   <xs:anyAttribute namespace="##other" processContents="lax"/>
610	   </xs:extension>
611	   </xs:complexContent>
612	   </xs:complexType>

614	   The <advSequenceNr> element contains the sequence number of the
615	   ADVERTISEMENT message the CONFIGURE refers to.

617	   The optional boolean <ack> element, set to "true", if present,
618	   indicates that the CONF message also acknowledge the referred
619	   advertisement, by applying in that way a piggibacking mechanism for
620	   simultaneously acknowledging and replying to the ADV message.  The
621	   <ack> element SHOULD not be present at all if an ADV ACK message has
622	   been already sent back to the MP.

624	   The most important content of the CONFIGURE message is the list of
625	   the capture encodings provided in the <captureEncodings> element.
626	   Such an element contains a sequence of capture encodings,
627	   representing the streams to be instantiated.

629	4.6.  CONFIGURE RESPONSE

631	   <!-- CONFIGURE RESPONSE MESSAGE TYPE -->
632	   <xs:complexType name="configureResponseMessageType">
633	   <xs:complexContent>
634	   <xs:extension base="clueMessageType">
635	   <xs:sequence>
636	   <xs:element name="responseCode" type="xs:short"/>
637	   <xs:element name="reasonString" type="xs:string"/>
638	   <xs:element name="confSequenceNr" type="xs:integer"/>
639	   <xs:any namespace="##other" processContents="lax" minOccurs="0"/>
640	   </xs:sequence>
641	   <xs:anyAttribute namespace="##other" processContents="lax"/>
642	   </xs:extension>
643	   </xs:complexContent>
644	   </xs:complexType>

646	   The CONF RESPONSE message is sent from the MP to the MC to
647	   communicate the processing result of requests carried in the
648	   previously received CONF message.  It contains a response code with a
649	   reason string indicating either the success or the failure (along
650	   with failure details) of a CONF request processing.  Following, the
651	   <confSequenceNr> field contains the number of the CONF message the
652	   response refers to.

654	4.7.  Response codes and reason strings

656	   Examples of response codes and strings are provided in the following
657	   table.

659	   +-----------------+----------------------+--------------------------+
660	   |                 |                      |                          |
661	   |  Response code  |  Response string     |       Description        |
662	   |                 |                      |                          |
663	   +-----------------+----------------------+--------------------------+
664	   |                 |                      |                          |
665	   |   200           |  Success             |  The request has been    |
666	   |                 |                      |  successfully processed. |
667	   |                 |                      |                          |
668	   +-----------------+----------------------+--------------------------+
669	   |                 |                      |                          |
670	   |   310           |  Bad syntax          |  The XML syntax of the   |
671	   |                 |                      |  message is not          |
672	   |                 |                      |  correct.                |
673	   +-----------------+----------------------+--------------------------+
674	   |                 |                      |                          |
675	   |   311           |  Invalid value       |  The message             |
676	   |                 |                      |  contains an invalid     |
677	   |                 |                      |  parameter value.        |
678	   +-----------------+----------------------+--------------------------+
679	   |                 |                      |                          |
680	   |   312           | Version not supported|  The protocol version    |
681	   |                 |                      |  used in the message     |
682	   |                 |                      |  is not supported.       |
683	   |                 |                      |                          |
684	   +-----------------+----------------------+--------------------------+
685	   |                 |                      |                          |
686	   |   313           |  Invalid sequencing  |  The sequence number of  |
687	   |                 |                      |  the message is out      |
688	   |                 |                      |  of date.                |
689	   +-----------------+----------------------+--------------------------+
690	   |                 |                      |                          |
691	   |   412           |  Invalid identifier  |  The identifier used in  |
692	   |                 |                      |  the message is          |
693	   |                 |                      |  not valid or unknown.   |
694	   +-----------------+----------------------+--------------------------+
695	   |                 |                      |                          |
696	   |   413           |  Conflicting values  |  The message             |
697	   |                 |                      |  contains values that    |
698	   |                 |                      |  cannot be used together.|
699	   +-----------------+----------------------+--------------------------+
700	   |                 |                      |                          |
701	   |   420           |  ADV Expired         |  The number of the ADV   |
702	   |                 |                      |  the CONF refers to is   |
703	   |                 |                      |  out of date.            |
704	   +-----------------+----------------------+--------------------------+
705	   |                 |                      |                          |
706	   |   510           | Version not supported|  The protocol version    |
707	   |                 |                      |  used in the message     |
708	   |                 |                      |  is not supported.       |
709	   |                 |                      |                          |
710	   +-----------------+----------------------+--------------------------+

712	   ...  TBC.

714	5.  Protocol state machines

716	   The CLUE protocol is an application protocol used between two CPs in
717	   order to properly configure a multimedia telepresence session.  CLUE
718	   protocol messages flow upon the CLUE Data Channel, a DTLS/SCTP
719	   channel established as depicted in [I-D.ietf-clue-signaling].  Over
720	   such a channel there are typically two CLUE streams between the
721	   channel terminations flowing in opposite directions.  In other words,
722	   typically, both channel terminations act simultaneously as a MP and
723	   as a MC.  We herein discuss the state machines associated,
724	   respectively, with the CLUE Participant, with the MC process and with
725	   the MP process.

727	6.  CLUE Participant's state machine

729	   The main state machines focus on the behavior of the CLUE Participant
730	   (CP) acting as a CLUE channel initiator/receiver (CI/CR).

732	   When the CLUE data channel set up starts ("start channel setup"), the
733	   CP moves from the IDLE state to the CHANNEL SETUP state.

735	   If the CLUE data channel is successfully set up ("channel
736	   established"), the CP moves from the CHANNEL SETUP state to the
737	   OPTIONS state.  Otherwise ("channel error"), it moves to the
738	   TERMINATED state.

740	   When in the OPTIONS state, the CP addresses the initiation phase
741	   where both parts agree on the version and on the options to be used
742	   in the subsequent CLUE messages exchange phase.  If the CP is the
743	   Channel Initiator (CI), it sends an OPTIONS message and waits for the
744	   OPTIONS response.  If the CP is the Channel Receiver (CR), it waits
745	   for the OPTIONS message and, as soon as it arrives, replies with the
746	   OPTIONS RESPONSE.  If the negotiation is successfully completed
747	   ("OPTIONS phase success"), the CP moves from the OPTIONS state to the
748	   ACTIVE state.  If the initiation phase fails ("OPTIONS phase
749	   failure"), the CP moves from the OPTIONS state to the TERMINATED
750	   state.  The initiation phase might fail because of one of the
751	   following reasons:

753	   1.  the CI receives an OPTIONS RESPONSE with an error response code

755	   2.  the CI does not receive any OPTIONS RESPONSE and a timeout error
756	       is raised

758	   3.  the CR does not receive any OPTIONS and a timeout error is raised

760	   When in the ACTIVE state, the CP starts the envisioned sub state
761	   machines (i.e., the MP state machine and the MC state machine)
762	   according to the roles it wants to play in the telepresence sessions.
763	   Such roles have been previously declared in the OPTIONS and OPTIONS
764	   RESPONSE messages involved in the initiation phase (see OPTIONS
765	   sections for the details).  When in the ACTIVE state, the CP
766	   delegates the sending and the processing of the CLUE messages to the
767	   appropriate MP/MC sub-state machines.  If the CP receives a further
768	   OPTIONS/OPTIONS RESPONSE message, it MUST ignore the message and stay
769	   in the ACTIVE state.

771	   When in the TERMINATED state, the CP MUST release all the resources
772	   allocated for the CLUE session (channel resources and application
773	   resources).  The TERMINATED state is reachable from each of the
774	   aforementioned states in case of connection errors ("channel error")
775	   or in case of the end of the session ("session ends").  The CP moves
776	   from the ACTIVE state to the TERMINATED one also when both the sub
777	   state machines are in the TERMINATED state (see sub state machine
778	   sections).

780	                                  +----+
781	                                  |IDLE|
782	                                  +-+--+
783	                                    |
784	                                    |  start
785	                                    |  channel
786	                                    v
787	             channel error/      +--------+
788	             session ends        | CHANNEL|
789	          +----------------------+ SETUP  |
790	          |                      +--+-----+
791	          |                         |
792	          |                         |  channel
793	          |                         |  established
794	          |  channel error/         v                 OPTIONS phase
795	          |  session ends         +-------+           failure
796	          +-----------------------+OPTIONS+--------------------------+
797	          |                       +-+-----+                          |
798	          |                         |                                |
799	          |                         |  OPTIONS phase                 |
800	          |                         |  success                       |
801	          |                         v                                |
802	          |   channel error/     +---------+                         |
803	          |   session ends       | ACTIVE  |                         |
804	          +----------------------+         |                         |
805	          |                      | +----+  +------------------+      |
806	          |                      | | MP |  |    send/receive  |      |
807	          |                      | +----+  |    CLUE messages |      |
808	          |                      |         |<-----------------+      |
809	          |                      | +----+  |                         |
810	          |                      | | MC |  |                         |
811	          |                      | +----+  |                         |
812	          |                      |         |                         |
813	          |                      +--+------+                         |
814	          |                         |                                |
815	          |                         |  both sub state machines       |
816	          |                         |  terminated                    |
817	          |                         v                                |
818	          |                       +----------+                       |
819	          +---------------------->|TERMINATED|<----------------------+
820	                                  +----------+

822	6.1.  Media Provider's state machine

824	   In the ADV state, the MP is preparing the ADV message reflecting its
825	   actual telepresence capabilities.

827	   After the ADV has been sent, the MP moves from the ADV state to the
828	   WAIT FOR ACK state.  If an ACK message with a successful response
829	   code arrives ("ACK received"), the MP moves to the WAIT FOR CONF
830	   state.  If an ACK with an error response code arrives ("NACK
831	   received") and the number of NACKs for the issued ADV is under the
832	   retry threshold, the MP moves back to the ADV state for preparing a
833	   new ADV.  The same happens if the waiting time for the ACK is fired a
834	   number of times under the retry threshold ("timeout && retry not
835	   expired"): also in this case, the MP goes back to the ADV state to
836	   send a new copy of the ADV.  If the number of retries overcomes the
837	   threshold, the MP moves from the WAIT FOR ACK state to the TERMINATED
838	   state.  When in the WAIT FOR ACK state, if a CONF+ACK message arrives
839	   ("CONF+ACK received"), the MP goes directly to the CONF RESPONSE
840	   state.  CONF+ACK messages referring to out-of-date ADVs should be
841	   ignored, i.e., they do not trigger any state transition.  If the
842	   telepresence settings of the MP change while in the WAIT FOR ACK
843	   state ("changed telepresence settings"), the MP has to create a new
844	   advertisement, so it switches from the WAIT FOR ACK state to the ADV
845	   state.

847	   When in the WAIT FOR CONF state, the MP is listening to the channel
848	   for a CONF request coming from the MC.  If a CONF arrives ("CONF
849	   received"), the MP switches to the CONF RESPONSE state.  In case of a
850	   timeout not exceeding the retry threshold ("timeout && retry not
851	   expired"), the MP moves back to the ADV state.  When the retry
852	   expires ("retry expired") the MP moves to the MP TERMINATED state.
853	   If the telepresence settings change in the meanwhile ("changed
854	   telepresence settings"), the MP moves from the WAIT FOR CONF back to
855	   the ADV state to create the new ADV to be sent to the MC.

857	   The MP in the CONF RESPONSE state is processing the received CONF in
858	   order to produce a CONF RESPONSE message.  If the MP is fine with the
859	   MC's configuration, then it sends a 200 OK CONF RESPONSE ("success
860	   CONF RESPONSE sent") and moves to the SDP O/A state.  If there are
861	   errors in the CONF processing, then the MP issues a CONF RESPONSE
862	   carrying an error response code ("error CONF RESPONSE sent") and, if
863	   under the retry treshold ("retry not expired"), it goes back to the
864	   WAIT FOR CONF state to wait for a new configuration request.  If the
865	   number of trials exceeds the retry threshold ("retry expired"), the
866	   state MP TERMINATED is reached.  Finally, if there are changes in the
867	   MP's telepresence settings, the MP switches to the ADV state.

869	   The MP in the SDP O/A state has successfully negotiated the media
870	   streams with the MC by means of the CLUE messages.  In order to
871	   actually instatiate the media streams, the MP in this state starts
872	   the SDP O/A by sending an SDP offer to the MC and then waiting for
873	   the MC's answer.  If the SDP O/A succeeds ("successful O/A
874	   completion"), i.e., the answer arrives and is successfully processed,
875	   the MP moves to the ESTABLISHED state.  Otherwise ("O/A failure"),
876	   the MP goes to the MP TERMINATED state.  If there are changes in the
877	   MP's telepresence settings, the MP moves back to the ADV state.

879	   In the ESTABLISHED state, the media streams instantiated are those
880	   described in the last successfully processed CONF message.  In case
881	   of changes in the telepresence offer of the MP ("changed telepresence
882	   settings"), the MP comes back to the ADV state to issue a new ADV.

884	+------------------------->+-----+<---------------------------+
885	|            +------------>| ADV |<-------------------+       |
886	|            |             +-+---+                    |       |timeout
887	|            |               |       NACK received    |       |&&
888	|            |       ADV sent|             &&         |       |retry
889	|            |               v       retry not expired|       |not
890	|     changed|             +--------+                 |       |expired
891	|telepresence+-------------+WAIT FOR+-----------------+       |
892	|    settings|   +---------+  ACK   +-------------------------+
893	|            |   |CONF+ACK +-+------+------------------------------------+
894	|            |   |received   |                                   timeout,|
895	|            |   |           |ACK received                        retry  |
896	|            |   |           v                                    expired|
897	+------------|-------------+--------+                                    |
898	timeout      +-------------+WAIT FOR+------------------------------------+
899	&&           |   |         |  CONF  |<-------------------------------+   |
900	retry        |   |         +-+------+                                |   |
901	not expired  |   |           |                                       |   |
902	             |   |           |CONF received                          |   |
903	             |   |           v               error CONF RESPONSE sent|   |
904	             |   +-------->+---------+        && retry not expired   |   |
905	             +-------------+CONF     |-------------------------------+   |
906	    +--------------------->|RESPONSE +-----------------------------------+
907	    |        |             +-+-------+           error CONF RESPONSE sent|
908	    |        |               |                           && retry expired|
909	    |        |               |  success                                  |
910	    |        |               |  CONF RESPONSE                            |
911	    |        |               |  sent                                     |
912	    |        |               v                                           |
913	    |        |             +--------+                                    |
914	    |        +-------------+SDP O/A +-------------------+                |
915	    +----------------------+-+------+                   |                |
916	    |        |               |                          | O/A failure    |
917	    |        |               | successful O/A           |                |
918	    |CONF    |               | completion               |                |
919	    |received|               v                          |                |
920	    |        |             +------------+               |                |
921	    |        +-------------+ESTABLISHED |               |                |
922	    +---------------------++------------+               |                |
923	                                                        |                |
924	                                                        |                |
925	                                                        |                |
926	                           +-----------+                |                |
927	                           !    MP     |                |                |
928	                           |TERMINATED |<---------------+                |
929	                           +-----------+<--------------------------------+

931	6.2.  Media Consumer's state machine

933	   An MC in the WAIT FOR ADV state is waiting for an ADV coming from the
934	   MP.  If the ADV arrives ("ADV received"), the MC reaches the
935	   PROCESSING ADV state.  Otherwise, the MC is stuck in the WAIT FOR ADV
936	   state.

938	   In the PROCESSING ADV state, the ADV is parsed by the MC.  If the ADV
939	   is successfully processed, there are two possibilities.  According to
940	   the first one, the MC issues a successful ACK message to the MP ("ACK
941	   sent") and moves to the CONF state.  In the second one, the MC sends
942	   a CONF message with the <ack> field set to "true" ("CONF+ACK sent")
943	   and goes directly to the WAIT FOR CONF RESPONSE state.

945	   If something goes wrong with the ADV parsing (bad syntax, missing XML
946	   elements, etc.), and the number of times this has happened is under
947	   the retry treshold, the MC sends a NACK message (an ACK with an error
948	   response code) to the MP describing the problem via a proper reason
949	   phrase.  In this way ("NACK sent && retry not expired"), the MC
950	   switches back to the WAIT FOR ADV state, waiting for a new ADV.  If
951	   the NACK retry expires ("retry expired"), the MC moves to the MC
952	   TERMINATED state.

954	   When in the CONF state, the MC is preparing the CONF request to be
955	   issued to the MP on the basis of the previously ACK-ed ADV.  When the
956	   CONF has been sent ("CONF sent"), the MC moves to the WAIT FOR CONF
957	   RESPONSE state.  If a new ADV arrives in the meanwhile, the MC goes
958	   back to the PREPARING ADV state.

960	   When the SDP information arrives, from the ADV RECEIVED or the ADV
961	   ACKED state the MC switches to the READY TO CONF state.  When the
962	   CONF request is ready, the MC sends it and moves to the TRYING state.
963	   If the ADV has not yet been sent, the MC can piggyback the ACK
964	   message inside the CONF request.

966	   In the WAIT FOR CONF RESPONSE state, the MC is waiting for the
967	   response to the issued CONF or CONF+ACK coming from the MP.  If a 200
968	   OK CONF RESPONSE message is received ("successful CONF RESPONSE
969	   received"), it means that the MP and the MC have successfully agreed
970	   on the media streams to be shared.  Then, the MC can move to the SDP
971	   O/A state, where it will instantiate the agreed-upon media streams.
972	   On the other hand, if an error response is received and the
973	   associated retry counter does not overcome the threshold ("error CONF
974	   RESPONSE received && retry not expired"), the MC moves back to the
975	   CONF state to prepare a new CONF request.  In case of "retry
976	   expired", the MC moves to the MC TERMINATED state.  If no CONF
977	   RESPONSE arrives at all, and the number of timeouts is under the
978	   threshold, the MC moves to the WAIT FOR ADV state, waiting for a new
979	   ADV.  If a new ADV is received in the WAIT FOR CONF RESPONSE state,
980	   the MC switches to the ADV PROCESSING state.

982	   When the MC is in the SDP O/A state, the telepresence session
983	   configuration has been set up at the CLUE application level according
984	   to the MC's preferences.  Both the MP and the MC have agreed on (and
985	   are aware of) the media streams to be exchanged within the call.  In
986	   this state, the MC waits for the SDP offer coming from the MP.  As
987	   soon as it arrives, the MC replies with an SDP answer.  If everything
988	   is ok with the SDP negotiation ("successful O/A completion"), the MC
989	   moves to the ESTABLISHED phase, otherwise ("O/A failure") it moves to
990	   the MC TERMINATED state.  While in the SDP O/A state, it might happen
991	   that the MC decides to change something in the call settings.  The MC
992	   then issues a new CONF ("CONF sent") and goes to wait for the new
993	   CONF RESPONSE in the WAIT FOR CONF RESPONSE state.  If a new ADV
994	   arrives from the MP ("ADV received"), it means that something has
995	   changed on the MP's side.  The MC then moves to the ADV PROCESSING
996	   state.

998	   In the ESTABLISHED state, the streams negotiated by means of the CLUE
999	   messages are instantiated on the media plane.  If the MC whishes to
1000	   change the media configuration, it issues a new CONF towards the MP
1001	   ("CONF sent") and moves to the CONF state.  In case of a new ADV
1002	   ("ADV received"), it switches to the ADV PROCESSING state.

1004	   The TERMINATED state is reachable from each of the aforementioned
1005	   states whenever the underlying channel is closed.  The corresponding
1006	   transitions have not been reported for the sake of simplicity.

1008	                           +----------+
1009	                           | WAIT FOR |
1010	                           |   ADV    |<-------------------------------+
1011	                           +----+-----+<--------+                      |
1012	                                |               |           timeout&&  |
1013	                        ADV     |      NACK sent|             retry    |
1014	                        received|      && retry |           not expired|
1015	                                v    not expired|                      |
1016	                           +-----------+--------+    retry expired     |
1017	                           |  ADV      +-------------------------------|--+
1018	                           | PROCESSING|<-----------------------+      |  |
1019	                           +-+-----+---+                        |      |  |
1020	                             |     |                            |      |  |
1021	                   CONF+ACK  |     |  ACK                       |      |  |
1022	                     sent    |     |  sent                      |      |  |
1023	                             |     v                            |      |  |
1024	                             |  +-----+                         |      |  |
1025	                             |  |CONF |            ADV received |      |  |
1026	            +------------------>|     +-------------------------+      |  |
1027	            |                |  +--+--+                         |      |  |
1028	            |error           |     |                            |      |  |
1029	            |CONF RESPONSE   |     | CONF                       |      |  |
1030	            |received&&      |     | sent      retry expired    |      |  |
1031	            |retry           |     |      +-------------------------------+
1032	            |not expired     v     v      |                     |      |  |
1033	            +-------------+---------------+        ADV received |      |  |
1034	               +--------->|   WAIT FOR    +---------------------+      |  |
1035	               |          |  CONF RESPONSE+----------------------------+  |
1036	               |          +-------+-------+                     |         |
1037	               |                  |                             |         |
1038	               |                  | successful                  |         |
1039	               |                  | CONF RESPONSE               |         |
1040	               |                  | received                    |         |
1041	               |CONF sent         v                ADV received |         |
1042	               +-------------+-------+--------------------------+         |
1043	               |             |SDP O/A|       O/A failure        |         |
1044	               |             +----+--+------------------------------+     |
1045	               |                  |                             |   |     |
1046	               |                  |successful                   |   |     |
1047	               |                  |O/A                          |   |     |
1048	               |                  |completion                   |   |     |
1049	               |                  v                             |   |     |
1050	               |CONF sent   +-----------+           ADV received|   |     |
1051	               +------------+ESTABLISHED+-----------------------+   |     |
1052	                            +-----------+                           |     |
1053	                                                                    |     |
1054	                                                                    |     |
1055	                                                                    |     |
1056	                             +-----------+<-------------------------+     |
1057	                             |   MC      |<-------------------------------+
1058	                             |TERMINATED |
1059	                             +-----------+

1061	7.  Versioning

1063	   CLUE protocol messages are XML messages compliant to the CLUE
1064	   protocol XML schema.  The version of the protocol corresponds to the
1065	   version of the schema.  Both client and server have to test the
1066	   compliance of the received messages with the XML schema of the CLUE
1067	   protocol.  If the compliance is not verified, the message cannot be
1068	   processed further.

1070	   Obviously, client and server cannot communicate if they do not share
1071	   exactly the same XML schema.  Such a schema is the one included in
1072	   the yet to come RFC, and associated with the CLUE URN
1073	   "urn:ietf:params:xml:ns:clue-message".  If all CLUE-enabled devices
1074	   use that schema there will be no interoperability problems due to
1075	   schema issues.

1077	   The version of the XML schema contained in the standard document
1078	   deriving from this draft will be 1.0.  The version usage is similar
1079	   in philosophy to XMPP (RFC6120).  A version number has major and
1080	   minor components, each a non-negative integer.  Major version changes
1081	   denote non-interoperable changes.  Minor version changes denote
1082	   schema changes that are backward compatible by ignoring unknown XML
1083	   elements, or other backward compatible changes.

1085	   The minor versions of the XML schema MUST be backward compatible, not
1086	   only in terms of schema but also semantically and procedurally as
1087	   well.  This means that they should define further features and
1088	   functionality besides those defined in the previous versions, in an
1089	   incremental way, without impacting the basic rules defined in the
1090	   previous version of the schema.  In this way, if a MP is able to
1091	   speak, e.g., version 1.5 of the protocol while the MC only
1092	   understands version 1.4, the MP should have no problem in reverting
1093	   the dialogue back to version 1.4 without exploiting 1.5 features and
1094	   functionality.

1096	   It is expected that, before the CLUE protocol XML schema reaches a
1097	   steady state, prototypes developed by different organizations will
1098	   conduct interoperability testing.  In that case, in order to
1099	   interoperate, they have to be compliant to the current version of the
1100	   XML schema, i.e., the one copied in the most up-to-date version of
1101	   the draft defining the CLUE protocol.  The versions of the non-
1102	   standard XML schema will be numbered as 0.01, 0.02, and so on.
1103	   During the standard development phase, the versions of the XML schema
1104	   will probably not be backward compatible so it is left to prototype
1105	   implementers the responsibility of keeping their products up to date.

1107	8.  Extensions and options

1109	   Although the standard version of the CLUE protocol XML schema will be
1110	   designed to thoroughly cope with the requirements emerging from the
1111	   application domain, new needs might arise and extensions can be
1112	   designed.  Extensions specify information and behaviors that are not
1113	   described in a certain version of the protocol.  They can relate to:

1115	   1.  new information, to be carried in the existing messages.  For
1116	       example, we may want to add more fields within an existing
1117	       message;

1119	   2.  new messages.  This is the case if there is no proper message for
1120	       a certain task, so a brand new CLUE message needs to be defined.

1122	   As to the first type of extensions, it is possible to distinguish
1123	   between protocol-specific and data model information.  Indeed, CLUE
1124	   messages are envelopes carrying both:

1126	   o  (i) XML elements defined within the CLUE protocol XML schema
1127	      itself (protocol-specific information)

1129	   o  (ii) other XML elements compliant to the CLUE data model schema
1130	      (data model information)

1132	   When new protocol-specific information is needed somewhere in the
1133	   protocol messages, it can be added in place of the <any> elements and
1134	   <anyAttribute> elements envisioned by the protocol schema.  The
1135	   policy currently defined in the protocol schema for handling <any>
1136	   and <anyAttribute> elements is:

1138	   o  elementFormDefault="qualified"

1140	   o  attributeFormDefault="unqualified"

1142	   In that case, the new information must be qualified by namespaces
1143	   other than "urn:ietf:params:xml:ns:clue-message" (the protocol URN)
1144	   and "urn:ietf:params:xml:ns:clue-info" (the data model URN).
1145	   Elements or attributes from unknown namespaces MUST be ignored.

1147	   The other matter concerns data model information.  Data model
1148	   information is defined by the XML schema associated with the URN
1149	   "urn:ietf:params:xml:ns:clue-info".  Also for the XML elements
1150	   defined in such a schema there are extensibility issues.  Those
1151	   issues are overcome by using <any> and <anyAttribute> placeholders.
1152	   Similarly to what said before, new information within data model
1153	   elements can be added in place of <any> and <anyAttribute> schema
1154	   elements, as long as they are properly namespace qualified.

1156	   On the other hand (second type of extensions), "extra" CLUE protocol
1157	   messages, i.e., messages not envisioned in the latest standard
1158	   version of the schema, can be needed.  In that case, the messages and
1159	   the associated behavior should be defined in external documents that
1160	   both communication parties must be aware of.

1162	   Both types of extensions, i.e., new information and new messages, can
1163	   be characterized by:

1165	   o  a name;
1166	   o  an external XML Schema defining the XML information and/or the XML
1167	      messages representing the extension;

1169	   o  the standard version of the protocol the extension refers to.

1171	   For that reason, the extensions can be represented by means of the
1172	   <option> element as defined below, which is carried within the
1173	   OPTIONS and OPTIONS RESPONSE messages to represent the extensions
1174	   supported by the CI and by the CR.

1176	   <!-- OPTION TYPE -->
1177	   <xs:complexType name="optionType">
1178	   <xs:sequence>
1179	   <xs:element name="name" type="xs:string" />
1180	   <xs:element name="schemaRef" type="xs:anyURI" minOccurs="0"/>
1181	   <xs:element name="version" type="xs:string" minOccurs="0"/>
1182	   <xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1183	   </xs:sequence>
1184	   <xs:anyAttribute namespace="##other" processContents="lax"/>
1185	   </xs:complexType>

1187	9.  XML Schema

1189	   In this section, the XML schema defining the CLUE messages is
1190	   provided.

1192	<?xml version="1.0" encoding="UTF-8" ?>
1193	<xs:schema
1194	version="0.02"
1195	targetNamespace="urn:ietf:params:xml:ns:clue-message"
1196	xmlns:tns="urn:ietf:params:xml:ns:clue-message"
1197	xmlns:xs="http://www.w3.org/2001/XMLSchema"
1198	xmlns:dm="urn:ietf:params:xml:ns:clue-info"
1199	xmlns="urn:ietf:params:xml:ns:clue-message"
1200	elementFormDefault="qualified"
1201	attributeFormDefault="unqualified">

1203	<!-- Import data model schema -->
1204	<xs:import namespace="urn:ietf:params:xml:ns:clue-info"
1205	schemaLocation="data-model-schema-07.xsd"/>

1207	<!-- Import RFC5261 schema -->
1208	<xs:include schemaLocation="rfc5261.xsd"/>
1209	<!-- ELEMENT DEFINITIONS -->
1210	<xs:element name="options" type="optionsMessageType"/>
1211	<xs:element name="optionsResponse" type="optionsResponseMessageType"/>
1212	<!--<xs:element name="optionsAck" type="optionsAcknowledgementMessageType"/>-->
1213	<xs:element name="advertisement" type="advertisementMessageType"/>
1214	<xs:element name="ack" type="advAcknowledgementMessageType"/>
1215	<xs:element name="configure" type="configureMessageType"/>
1216	<xs:element name="configureResponse" type="configureResponseMessageType"/>

1218	<!-- CLUE MESSAGE TYPE -->
1219	<xs:complexType name="clueMessageType" abstract="true">
1220	<xs:sequence>
1221	<xs:element name="clueId" type="xs:string"/>
1222	<xs:element name="sequenceNr" type="xs:unsignedInt"/>
1223	</xs:sequence>
1224	<xs:attribute name="protocol" type="xs:string" fixed="CLUE" use="required"/>
1225	<xs:attribute name="v" type="xs:string" use="required"/>
1226	</xs:complexType>

1228	<!-- CLUE OPTIONS -->
1229	<xs:complexType name="optionsMessageType">
1230	<xs:complexContent>
1231	<xs:extension base="clueMessageType">
1232	<xs:sequence>
1233	<xs:element name="mediaProvider" type="xs:boolean"/>
1234	<xs:element name="mediaConsumer" type="xs:boolean"/>
1235	<xs:element name="supportedVersions" type="versionsListType" minOccurs="0"/>
1236	<xs:element name="supportedOptions" type="optionsListType" minOccurs="0"/>
1237	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1238	</xs:sequence>
1239	<xs:anyAttribute namespace="##other" processContents="lax"/>
1240	</xs:extension>
1241	</xs:complexContent>
1242	</xs:complexType>

1244	<!-- VERSIONS LIST TYPE -->
1245	<xs:complexType name="versionsListType">
1246	<xs:sequence>
1247	<xs:element name="version" type="xs:string" minOccurs="1"
1248	 maxOccurs="unbounded"/>
1249	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1250	</xs:sequence>
1251	<xs:anyAttribute namespace="##other" processContents="lax"/>
1252	</xs:complexType>

1254	<!-- OPTIONS LIST TYPE -->
1255	<xs:complexType name="optionsListType">
1256	<xs:sequence>
1257	<xs:element name="option" type="optionType" minOccurs="1"
1258	 maxOccurs="unbounded"/>
1259	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1260	</xs:sequence>
1261	<xs:anyAttribute namespace="##other" processContents="lax"/>
1262	</xs:complexType>

1264	<!-- OPTION TYPE -->
1265	<xs:complexType name="optionType">
1266	<xs:sequence>
1267	<xs:element name="name" type="xs:string" />
1268	<xs:element name="schemaRef" type="xs:anyURI" minOccurs="0"/>
1269	<xs:element name="version" type="xs:string" minOccurs="0"/>
1270	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1271	</xs:sequence>
1272	<xs:anyAttribute namespace="##other" processContents="lax"/>
1273	</xs:complexType>

1275	<!-- CLUE OPTIONS RESPONSE (2 WAY) -->
1276	<xs:complexType name="optionsResponseMessageType">
1277	<xs:complexContent>
1278	<xs:extension base="clueMessageType">
1279	<xs:sequence>
1280	<xs:element name="responseCode" type="xs:short"/>
1281	<xs:element name="reasonString" type="xs:string"/>
1282	<xs:element name="mediaProvider" type="xs:boolean" minOccurs="0"/>
1283	<xs:element name="mediaConsumer" type="xs:boolean" minOccurs="0"/>
1284	<xs:element name="version" type="xs:string" minOccurs="0"/>
1285	<xs:element name="commonOptions" type="optionsListType" minOccurs="0"/>
1286	<xs:any namespace="##other"
1287	processContents="lax" minOccurs="0"/>
1288	</xs:sequence>
1289	<xs:anyAttribute namespace="##other" processContents="lax"/>
1290	</xs:extension>
1291	</xs:complexContent>
1292	</xs:complexType>

1294	<!-- CLUE ADVERTISEMENT MESSAGE TYPE -->
1295	<xs:complexType name="advertisementMessageType">
1296	<xs:complexContent>
1297	<xs:extension base="clueMessageType">
1298	<xs:choice>
1299	<!-- full adv body -->
1300	<xs:sequence>
1301	        <!-- mandatory fields -->
1302	        <xs:element name="mediaCaptures" type="dm:mediaCapturesType"/>
1303	        <xs:element name="encodingGroups" type="dm:encodingGroupsType"/>
1304	        <xs:element name="captureScenes" type="dm:captureScenesType"/>
1305	        <!-- optional fields -->
1306	        <xs:element name="simultaneousSets" type="dm:simultaneousSetsType"
1307	         minOccurs="0"/>
1308	        <xs:element name="globalViews" type="dm:globalViewsType"
1309	         minOccurs="0"/>
1310	        <xs:element name="people" type="dm:peopleType" minOccurs="0"/>
1311	        <xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1312	</xs:sequence>
1313	<!-- partial adv body -->
1314	<xs:sequence minOccurs="0" maxOccurs="unbounded">
1315	 <xs:choice>
1316	  <!-- add some content -->
1317	  <xs:element name="add">
1318	   <xs:complexType mixed="true">
1319	    <xs:complexContent>
1320	     <xs:extension base="add">
1321	      <xs:anyAttribute processContents="lax"/>
1322	     </xs:extension>
1323	    </xs:complexContent>
1324	   </xs:complexType>
1325	  </xs:element>
1326	  <!-- remove some content -->
1327	  <xs:element name="remove">
1328	   <xs:complexType>
1329	    <xs:complexContent>
1330	     <xs:extension base="remove">
1331	      <xs:anyAttribute processContents="lax"/>
1332	     </xs:extension>
1333	    </xs:complexContent>
1334	   </xs:complexType>
1335	  </xs:element>
1336	  <!-- replace some content -->
1337	  <xs:element name="replace">
1338	   <xs:complexType mixed="true">
1339	    <xs:complexContent>
1340	     <xs:extension base="replace">
1341	      <xs:anyAttribute processContents="lax"/>
1342	     </xs:extension>
1343	    </xs:complexContent>
1344	   </xs:complexType>
1345	  </xs:element>
1346	  <!-- allow extension elements from other namespaces -->
1347	  <xs:any namespace="##other" processContents="lax"/>
1348	   </xs:choice>
1349	</xs:sequence>
1350	</xs:choice>
1351	<xs:anyAttribute namespace="##other" processContents="lax"/>
1352	</xs:extension>
1353	</xs:complexContent>
1354	</xs:complexType>

1356	<!-- ADV ACK MESSAGE TYPE -->
1357	<xs:complexType name="advAcknowledgementMessageType">
1358	<xs:complexContent>
1359	<xs:extension base="clueMessageType">
1360	<xs:sequence>
1361	<xs:element name="responseCode" type="xs:short"/>
1362	<xs:element name="reasonString" type="xs:string"/>
1363	<xs:element name="advSequenceNr" type="xs:unsignedInt"/>
1364	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1365	</xs:sequence>
1366	<xs:anyAttribute namespace="##other" processContents="lax"/>
1367	</xs:extension>
1368	</xs:complexContent>
1369	</xs:complexType>

1371	<!-- CLUE CONFIGURE MESSAGE TYPE -->
1372	<xs:complexType name="configureMessageType">
1373	<xs:complexContent>
1374	<xs:extension base="clueMessageType">
1375	<xs:sequence>
1376	<!-- mandatory fields -->
1377	<xs:element name="advSequenceNr" type="xs:unsignedInt"/>
1378	<xs:element name="ack" type="xs:boolean" minOccurs="0" fixed="true"/>
1379	<xs:element name="captureEncodings" type="dm:captureEncodingsType"
1380	 minOccurs="0"/>
1381	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1382	</xs:sequence>
1383	<xs:anyAttribute namespace="##other" processContents="lax"/>
1384	</xs:extension>
1385	</xs:complexContent>
1386	</xs:complexType>

1388	<!-- CONFIGURE RESPONSE MESSAGE TYPE -->
1389	<xs:complexType name="configureResponseMessageType">
1390	<xs:complexContent>
1391	<xs:extension base="clueMessageType">
1392	<xs:sequence>
1393	<xs:element name="responseCode" type="xs:short"/>
1394	<xs:element name="reasonString" type="xs:string"/>
1395	<xs:element name="confSequenceNr" type="xs:integer"/>
1396	<xs:any namespace="##other" processContents="lax" minOccurs="0"/>
1397	</xs:sequence>
1398	<xs:anyAttribute namespace="##other" processContents="lax"/>
1399	</xs:extension>
1400	</xs:complexContent>
1401	</xs:complexType>

1403	</xs:schema>

1405	10.  ADVERTISEMENT examples

1407	   In the following we provide two examples of ADVERTISEMENT
1408	   representing the telepresence environment described in
1409	   [I-D.ietf-clue-data-model-schema], Section 22 "Sample XML file" and
1410	   Section 23 "MCC example" respectively.  The last subsection is about
1411	   a partial ADV message example.

1413	10.1.  Simple ADV

1415	   The associated Media Provider's telepresence capabilities are
1416	   described in [I-D.ietf-clue-data-model-schema], Section 22 "Sample
1417	   XML file".  The XML file can be downloaded here:
1418	   http://wpage.unina.it/spromano/CLUE/.

1420	<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
1421	<advertisement xmlns="urn:ietf:params:xml:ns:clue-message"
1422	               xmlns:ns2="urn:ietf:params:xml:ns:clue-info"
1423	               xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0"
1424	               protocol="CLUE" v="0.0">
1425	    <clueId>Napoli</clueId>
1426	    <sequenceNr>45</sequenceNr>
1427	    <mediaCaptures>
1428	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1429	         xsi:type="ns2:videoCaptureType"  captureID="AC0" mediaType="video">

1431	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1432	            <ns2:encGroupIDREF>EG1</ns2:encGroupIDREF>
1433	            <ns2:spatialInformation>
1434	                <ns2:capturePoint>
1435	                    <ns2:x>0.5</ns2:x>
1436	                    <ns2:y>1.0</ns2:y>
1437	                    <ns2:z>0.5</ns2:z>
1438	                    <ns2:lineOfCapturePoint>
1439	                        <ns2:x>0.5</ns2:x>
1440	                        <ns2:y>0.0</ns2:y>
1441	                        <ns2:z>0.5</ns2:z>

1443	                    </ns2:lineOfCapturePoint>
1444	                </ns2:capturePoint>
1445	            </ns2:spatialInformation>
1446	            <ns2:individual>true</ns2:individual>
1447	            <ns2:description lang="en">main audio from the room</ns2:description>
1448	            <ns2:priority>1</ns2:priority>
1449	            <ns2:lang>it</ns2:lang>
1450	            <ns2:mobility>static</ns2:mobility>
1451	            <ns2:view>room</ns2:view>
1452	            <ns2:capturedPeople>
1453	                <ns2:personIDREF>alice</ns2:personIDREF>
1454	                <ns2:personIDREF>bob</ns2:personIDREF>
1455	                <ns2:personIDREF>ciccio</ns2:personIDREF>
1456	            </ns2:capturedPeople>
1457	            <ns2:maxCaptureEncodings>1</ns2:maxCaptureEncodings>
1458	        </ns2:mediaCapture>
1459	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1460	         xsi:type="ns2:videoCaptureType" mediaType="video" captureID="VC0">

1462	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1463	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
1464	            <ns2:spatialInformation>
1465	                <ns2:capturePoint>
1466	                    <ns2:x>0.5</ns2:x>
1467	                    <ns2:y>1.0</ns2:y>
1468	                    <ns2:z>0.5</ns2:z>
1469	                    <ns2:lineOfCapturePoint>
1470	                        <ns2:x>0.5</ns2:x>
1471	                        <ns2:y>0.0</ns2:y>
1472	                        <ns2:z>0.5</ns2:z>
1473	                    </ns2:lineOfCapturePoint>
1474	                </ns2:capturePoint>
1475	            </ns2:spatialInformation>
1476	            <ns2:individual>true</ns2:individual>
1477	            <ns2:description lang="en">left camera video capture
1478	            </ns2:description>
1479	            <ns2:priority>1</ns2:priority>
1480	            <ns2:lang>it</ns2:lang>
1481	            <ns2:mobility>static</ns2:mobility>
1482	            <ns2:view>individual</ns2:view>
1483	            <ns2:capturedPeople>
1484	                <ns2:personIDREF>ciccio</ns2:personIDREF>
1485	            </ns2:capturedPeople>
1486	            <ns2:maxCaptureEncodings>2</ns2:maxCaptureEncodings>
1487	        </ns2:mediaCapture>
1488	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1489	         xsi:type="ns2:videoCaptureType" mediaType="video" captureID="VC1">
1490	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1491	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
1492	            <ns2:spatialInformation>
1493	                <ns2:capturePoint>
1494	                    <ns2:x>0.5</ns2:x>
1495	                    <ns2:y>1.0</ns2:y>
1496	                    <ns2:z>0.5</ns2:z>
1497	                    <ns2:lineOfCapturePoint>
1498	                        <ns2:x>0.5</ns2:x>
1499	                        <ns2:y>0.0</ns2:y>
1500	                        <ns2:z>0.5</ns2:z>
1501	                    </ns2:lineOfCapturePoint>
1502	                </ns2:capturePoint>
1503	            </ns2:spatialInformation>
1504	            <ns2:individual>true</ns2:individual>
1505	            <ns2:description lang="en">central camera video capture
1506	            </ns2:description>
1507	            <ns2:priority>1</ns2:priority>
1508	            <ns2:lang>it</ns2:lang>
1509	            <ns2:mobility>static</ns2:mobility>
1510	            <ns2:view>individual</ns2:view>
1511	            <ns2:capturedPeople>
1512	                <ns2:personIDREF>alice</ns2:personIDREF>
1513	            </ns2:capturedPeople>
1514	            <ns2:maxCaptureEncodings>2</ns2:maxCaptureEncodings>
1515	        </ns2:mediaCapture>
1516	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1517	         xsi:type="ns2:videoCaptureType" mediaType="video" captureID="VC2">

1519	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1520	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
1521	            <ns2:spatialInformation>
1522	                <ns2:capturePoint>
1523	                    <ns2:x>0.5</ns2:x>
1524	                    <ns2:y>1.0</ns2:y>
1525	                    <ns2:z>0.5</ns2:z>
1526	                    <ns2:lineOfCapturePoint>
1527	                        <ns2:x>0.5</ns2:x>
1528	                        <ns2:y>0.0</ns2:y>
1529	                        <ns2:z>0.5</ns2:z>
1530	                    </ns2:lineOfCapturePoint>
1531	                </ns2:capturePoint>
1532	            </ns2:spatialInformation>
1533	            <ns2:individual>true</ns2:individual>
1534	            <ns2:description lang="en">right camera video capture
1535	            </ns2:description>
1536	            <ns2:priority>1</ns2:priority>
1537	            <ns2:lang>it</ns2:lang>
1538	            <ns2:mobility>static</ns2:mobility>
1539	            <ns2:view>individual</ns2:view>
1540	            <ns2:capturedPeople>
1541	                <ns2:personIDREF>bob</ns2:personIDREF>
1542	            </ns2:capturedPeople>
1543	            <ns2:maxCaptureEncodings>2</ns2:maxCaptureEncodings>
1544	        </ns2:mediaCapture>
1545	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1546	         xsi:type="ns2:videoCaptureType" mediaType="video" captureID="VC3">

1548	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1549	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
1550	            <ns2:nonSpatiallyDefinable>true</ns2:nonSpatiallyDefinable>
1551	            <ns2:composed>false</ns2:composed>
1552	            <ns2:switched>true</ns2:switched>
1553	            <ns2:policy>Soundlevel:0</ns2:policy>
1554	            <ns2:maxCaptures>1</ns2:maxCaptures>
1555	            <ns2:description lang="en">loudest room segment</ns2:description>
1556	            <ns2:priority>1</ns2:priority>
1557	            <ns2:lang>it</ns2:lang>
1558	            <ns2:mobility>static</ns2:mobility>
1559	            <ns2:view>individual</ns2:view>
1560	            <ns2:maxCaptureEncodings>1</ns2:maxCaptureEncodings>
1561	        </ns2:mediaCapture>
1562	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1563	         xsi:type="ns2:videoCaptureType" mediaType="video" captureID="VC4">

1565	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1566	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
1567	            <ns2:spatialInformation>
1568	                <ns2:capturePoint>
1569	                    <ns2:x>0.5</ns2:x>
1570	                    <ns2:y>1.0</ns2:y>
1571	                    <ns2:z>0.5</ns2:z>
1572	                    <ns2:lineOfCapturePoint>
1573	                        <ns2:x>0.5</ns2:x>
1574	                        <ns2:y>0.0</ns2:y>
1575	                        <ns2:z>0.5</ns2:z>
1576	                    </ns2:lineOfCapturePoint>
1577	                </ns2:capturePoint>
1578	            </ns2:spatialInformation>
1579	            <ns2:individual>true</ns2:individual>
1580	            <ns2:description lang="en">zoomed out view of all people in
1581	            the room
1582	            </ns2:description>
1583	            <ns2:priority>1</ns2:priority>
1584	            <ns2:lang>it</ns2:lang>
1585	            <ns2:mobility>static</ns2:mobility>
1586	            <ns2:view>room</ns2:view>
1587	            <ns2:capturedPeople>
1588	                <ns2:personIDREF>alice</ns2:personIDREF>
1589	                <ns2:personIDREF>bob</ns2:personIDREF>
1590	                <ns2:personIDREF>ciccio</ns2:personIDREF>
1591	            </ns2:capturedPeople>
1592	            <ns2:maxCaptureEncodings>1</ns2:maxCaptureEncodings>
1593	        </ns2:mediaCapture>
1594	    </mediaCaptures>
1595	    <encodingGroups>
1596	        <ns2:encodingGroup encodingGroupID="EG0">
1597	            <ns2:maxGroupBandwidth>600000</ns2:maxGroupBandwidth>
1598	            <ns2:encodingIDList>
1599	                <ns2:encID>ENC1</ns2:encID>
1600	                <ns2:encID>ENC2</ns2:encID>
1601	                <ns2:encID>ENC3</ns2:encID>
1602	            </ns2:encodingIDList>
1603	        </ns2:encodingGroup>
1604	        <ns2:encodingGroup encodingGroupID="EG1">
1605	            <ns2:maxGroupBandwidth>300000</ns2:maxGroupBandwidth>
1606	            <ns2:encodingIDList>
1607	                <ns2:encID>ENC4</ns2:encID>
1608	                <ns2:encID>ENC5</ns2:encID>
1609	            </ns2:encodingIDList>
1610	        </ns2:encodingGroup>
1611	    </encodingGroups>
1612	    <captureScenes>
1613	        <ns2:captureScene scale="unknown" sceneID="CS1">
1614	            <ns2:sceneViews>
1615	                <ns2:sceneView sceneViewID="SE1">
1616	                    <ns2:mediaCaptureIDs>
1617	                        <ns2:captureIDREF>VC0</ns2:captureIDREF>
1618	                        <ns2:captureIDREF>VC1</ns2:captureIDREF>
1619	                        <ns2:captureIDREF>VC2</ns2:captureIDREF>
1620	                    </ns2:mediaCaptureIDs>
1621	                </ns2:sceneView>
1622	                <ns2:sceneView sceneViewID="SE2">
1623	                    <ns2:mediaCaptureIDs>
1624	                        <ns2:captureIDREF>VC3</ns2:captureIDREF>
1625	                    </ns2:mediaCaptureIDs>
1626	                </ns2:sceneView>
1627	                <ns2:sceneView sceneViewID="SE3">
1628	                    <ns2:mediaCaptureIDs>
1629	                        <ns2:captureIDREF>VC4</ns2:captureIDREF>
1630	                    </ns2:mediaCaptureIDs>
1631	                </ns2:sceneView>
1632	                <ns2:sceneView sceneViewID="SE4">
1633	                    <ns2:mediaCaptureIDs>
1634	                        <ns2:captureIDREF>VC4</ns2:captureIDREF>
1635	                    </ns2:mediaCaptureIDs>
1636	                </ns2:sceneView>
1637	            </ns2:sceneViews>
1638	        </ns2:captureScene>
1639	    </captureScenes>
1640	    <simultaneousSets>
1641	        <ns2:simultaneousSet setID="SS1">
1642	            <ns2:mediaCaptureIDREF>VC3</ns2:mediaCaptureIDREF>
1643	            <ns2:sceneViewIDREF>SE1</ns2:sceneViewIDREF>
1644	        </ns2:simultaneousSet>
1645	        <ns2:simultaneousSet setID="SS2">
1646	            <ns2:mediaCaptureIDREF>VC0</ns2:mediaCaptureIDREF>
1647	            <ns2:mediaCaptureIDREF>VC2</ns2:mediaCaptureIDREF>
1648	            <ns2:mediaCaptureIDREF>VC4</ns2:mediaCaptureIDREF>
1649	            <ns2:mediaCaptureIDREF>VC3</ns2:mediaCaptureIDREF>
1650	        </ns2:simultaneousSet>
1651	    </simultaneousSets>
1652	    <people>
1653	        <ns2:person personID="bob">
1654	            <ns2:personInfo>
1655	                <ns3:fn>
1656	                    <ns3:text>Bob</ns3:text>
1657	                </ns3:fn>
1658	            </ns2:personInfo>
1659	            <ns2:personType>minute taker</ns2:personType>
1660	        </ns2:person>
1661	        <ns2:person personID="alice">
1662	            <ns2:personInfo>
1663	                <ns3:fn>
1664	                    <ns3:text>Alice</ns3:text>
1665	                </ns3:fn>
1666	            </ns2:personInfo>
1667	            <ns2:personType>presenter</ns2:personType>
1668	        </ns2:person>
1669	        <ns2:person personID="ciccio">
1670	            <ns2:personInfo>
1671	                <ns3:fn>
1672	                    <ns3:text>Ciccio</ns3:text>
1673	                </ns3:fn>
1674	            </ns2:personInfo>
1675	            <ns2:personType>chairman</ns2:personType>
1676	            <ns2:personType>timekeeper</ns2:personType>
1677	        </ns2:person>
1678	    </people>
1679	</advertisement>
1680	10.2.  ADV with MCCs

1682	   The associated Media Provider's telepresence capabilities are
1683	   described in [I-D.ietf-clue-data-model-schema], Section 23 "MCC
1684	   example".  The XML file can be downloaded here:
1685	   http://wpage.unina.it/spromano/CLUE/.

1687	<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
1688	<advertisement xmlns="urn:ietf:params:xml:ns:clue-message"
1689	 xmlns:ns2="urn:ietf:params:xml:ns:clue-info"
1690	 xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0" protocol="CLUE" v="0.1">
1691	    <clueId>Napoli CLUE Endpoint</clueId>
1692	    <sequenceNr>34</sequenceNr>
1693	    <mediaCaptures>
1694	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1695	         xsi:type="ns2:videoCaptureType" mediaType="video" captureID="AC0">

1697	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1698	            <ns2:encGroupIDREF>EG1</ns2:encGroupIDREF>
1699	            <ns2:spatialInformation>
1700	                <ns2:capturePoint>
1701	                    <ns2:x>0.5</ns2:x>
1702	                    <ns2:y>1.0</ns2:y>
1703	                    <ns2:z>0.5</ns2:z>
1704	                    <ns2:lineOfCapturePoint>
1705	                        <ns2:x>0.5</ns2:x>
1706	                        <ns2:y>0.0</ns2:y>
1707	                        <ns2:z>0.5</ns2:z>
1708	                    </ns2:lineOfCapturePoint>
1709	                </ns2:capturePoint>
1710	            </ns2:spatialInformation>
1711	            <ns2:individual>true</ns2:individual>
1712	            <ns2:description lang="en">main audio from the room</ns2:description>
1713	            <ns2:priority>1</ns2:priority>
1714	            <ns2:lang>it</ns2:lang>
1715	            <ns2:mobility>static</ns2:mobility>
1716	            <ns2:view>room</ns2:view>
1717	            <ns2:capturedPeople>
1718	                <ns2:personIDREF>alice</ns2:personIDREF>
1719	                <ns2:personIDREF>bob</ns2:personIDREF>
1720	                <ns2:personIDREF>ciccio</ns2:personIDREF>
1721	            </ns2:capturedPeople>
1722	            <ns2:maxCaptureEncodings>1</ns2:maxCaptureEncodings>
1723	        </ns2:mediaCapture>
1724	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1725	         xsi:type="ns2:videoCaptureType" captureID="VC0" mediaType="video" >
1726	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1727	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
1728	            <ns2:spatialInformation>
1729	                <ns2:capturePoint>
1730	                    <ns2:x>0.5</ns2:x>
1731	                    <ns2:y>1.0</ns2:y>
1732	                    <ns2:z>0.5</ns2:z>
1733	                    <ns2:lineOfCapturePoint>
1734	                        <ns2:x>0.5</ns2:x>
1735	                        <ns2:y>0.0</ns2:y>
1736	                        <ns2:z>0.5</ns2:z>
1737	                    </ns2:lineOfCapturePoint>
1738	                </ns2:capturePoint>
1739	            </ns2:spatialInformation>
1740	            <ns2:individual>true</ns2:individual>
1741	            <ns2:description lang="en">left camera video capture</ns2:description>
1742	            <ns2:priority>1</ns2:priority>
1743	            <ns2:lang>it</ns2:lang>
1744	            <ns2:mobility>static</ns2:mobility>
1745	            <ns2:view>individual</ns2:view>
1746	            <ns2:capturedPeople>
1747	                <ns2:personIDREF>ciccio</ns2:personIDREF>
1748	            </ns2:capturedPeople>
1749	            <ns2:maxCaptureEncodings>2</ns2:maxCaptureEncodings>
1750	        </ns2:mediaCapture>
1751	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1752	        xsi:type="ns2:videoCaptureType" captureID="VC1" mediaType="video">
1753	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1754	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
1755	            <ns2:spatialInformation>
1756	                <ns2:capturePoint>
1757	                    <ns2:x>0.5</ns2:x>
1758	                    <ns2:y>1.0</ns2:y>
1759	                    <ns2:z>0.5</ns2:z>
1760	                    <ns2:lineOfCapturePoint>
1761	                        <ns2:x>0.5</ns2:x>
1762	                        <ns2:y>0.0</ns2:y>
1763	                        <ns2:z>0.5</ns2:z>
1764	                    </ns2:lineOfCapturePoint>
1765	                </ns2:capturePoint>
1766	            </ns2:spatialInformation>
1767	            <ns2:individual>true</ns2:individual>
1768	            <ns2:description lang="en">central camera video capture
1769	            </ns2:description>
1770	            <ns2:priority>1</ns2:priority>
1771	            <ns2:lang>it</ns2:lang>
1772	            <ns2:mobility>static</ns2:mobility>
1773	            <ns2:view>individual</ns2:view>
1774	            <ns2:capturedPeople>
1775	                <ns2:personIDREF>alice</ns2:personIDREF>
1776	            </ns2:capturedPeople>
1777	            <ns2:maxCaptureEncodings>2</ns2:maxCaptureEncodings>
1778	        </ns2:mediaCapture>
1779	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1780	        xsi:type="ns2:videoCaptureType" captureID="VC2" mediaType="video" >
1781	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1782	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
1783	            <ns2:spatialInformation>
1784	                <ns2:capturePoint>
1785	                    <ns2:x>0.5</ns2:x>
1786	                    <ns2:y>1.0</ns2:y>
1787	                    <ns2:z>0.5</ns2:z>
1788	                    <ns2:lineOfCapturePoint>
1789	                        <ns2:x>0.5</ns2:x>
1790	                        <ns2:y>0.0</ns2:y>
1791	                        <ns2:z>0.5</ns2:z>
1792	                    </ns2:lineOfCapturePoint>
1793	                </ns2:capturePoint>
1794	            </ns2:spatialInformation>
1795	            <ns2:individual>true</ns2:individual>
1796	            <ns2:description lang="en">right camera video capture
1797	            </ns2:description>
1798	            <ns2:priority>1</ns2:priority>
1799	            <ns2:lang>it</ns2:lang>
1800	            <ns2:mobility>static</ns2:mobility>
1801	            <ns2:view>individual</ns2:view>
1802	            <ns2:capturedPeople>
1803	                <ns2:personIDREF>bob</ns2:personIDREF>
1804	            </ns2:capturedPeople>
1805	            <ns2:maxCaptureEncodings>2</ns2:maxCaptureEncodings>
1806	        </ns2:mediaCapture>
1807	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1808	        xsi:type="ns2:videoCaptureType" captureID="VC3" mediaType="video" >
1809	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1810	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
1811	            <ns2:nonSpatiallyDefinable>true</ns2:nonSpatiallyDefinable>
1812	            <ns2:content>
1813	                <ns2:sceneViewIDREF>SE1</ns2:sceneViewIDREF>
1814	            </ns2:content>
1815	            <ns2:policy>Soundlevel:0</ns2:policy>
1816	            <ns2:maxCaptures>1</ns2:maxCaptures>
1817	            <ns2:description lang="en">loudest room segment</ns2:description>
1818	            <ns2:priority>1</ns2:priority>
1819	            <ns2:lang>it</ns2:lang>
1820	            <ns2:mobility>static</ns2:mobility>
1821	            <ns2:view>individual</ns2:view>
1822	            <ns2:maxCaptureEncodings>1</ns2:maxCaptureEncodings>
1823	        </ns2:mediaCapture>
1824	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1825	        xsi:type="ns2:videoCaptureType"  captureID="VC4" mediaType="video">
1826	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1827	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
1828	            <ns2:spatialInformation>
1829	                <ns2:capturePoint>
1830	                    <ns2:x>0.5</ns2:x>
1831	                    <ns2:y>1.0</ns2:y>
1832	                    <ns2:z>0.5</ns2:z>
1833	                    <ns2:lineOfCapturePoint>
1834	                        <ns2:x>0.5</ns2:x>
1835	                        <ns2:y>0.0</ns2:y>
1836	                        <ns2:z>0.5</ns2:z>
1837	                    </ns2:lineOfCapturePoint>
1838	                </ns2:capturePoint>
1839	            </ns2:spatialInformation>
1840	            <ns2:individual>true</ns2:individual>
1841	            <ns2:description lang="en">zoomed out view of all people in the room
1842	            </ns2:description>
1843	            <ns2:priority>1</ns2:priority>
1844	            <ns2:lang>it</ns2:lang>
1845	            <ns2:mobility>static</ns2:mobility>
1846	            <ns2:view>room</ns2:view>
1847	            <ns2:capturedPeople>
1848	                <ns2:personIDREF>alice</ns2:personIDREF>
1849	                <ns2:personIDREF>bob</ns2:personIDREF>
1850	                <ns2:personIDREF>ciccio</ns2:personIDREF>
1851	            </ns2:capturedPeople>
1852	            <ns2:maxCaptureEncodings>1</ns2:maxCaptureEncodings>
1853	        </ns2:mediaCapture>
1854	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1855	        xsi:type="ns2:videoCaptureType"  captureID="VC5" mediaType="video">
1856	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1857	            <ns2:nonSpatiallyDefinable>true</ns2:nonSpatiallyDefinable>
1858	            <ns2:content>
1859	                <ns2:sceneViewIDREF>SE1</ns2:sceneViewIDREF>
1860	            </ns2:content>
1861	            <ns2:policy>Soundlevel:1</ns2:policy>
1862	            <ns2:maxCaptures>1</ns2:maxCaptures>
1863	            <ns2:description lang="en">penultimate loudest room segment
1864	            </ns2:description>
1865	            <ns2:priority>1</ns2:priority>
1866	            <ns2:lang>it</ns2:lang>
1867	            <ns2:mobility>static</ns2:mobility>
1868	            <ns2:view>individual</ns2:view>
1869	            <ns2:maxCaptureEncodings>1</ns2:maxCaptureEncodings>

1871	        </ns2:mediaCapture>
1872	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1873	        xsi:type="ns2:videoCaptureType"  captureID="VC6" mediaType="video">
1874	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1875	            <ns2:nonSpatiallyDefinable>true</ns2:nonSpatiallyDefinable>
1876	            <ns2:content>
1877	                <ns2:sceneViewIDREF>SE1</ns2:sceneViewIDREF>
1878	            </ns2:content>
1879	            <ns2:composed>false</ns2:composed>
1880	            <ns2:switched>true</ns2:switched>
1881	            <ns2:policy>Soundlevel:2</ns2:policy>
1882	            <ns2:maxCaptures>1</ns2:maxCaptures>
1883	            <ns2:description lang="en">last but two loudest room segment
1884	            </ns2:description>
1885	            <ns2:priority>1</ns2:priority>
1886	            <ns2:lang>it</ns2:lang>
1887	            <ns2:mobility>static</ns2:mobility>
1888	            <ns2:view>individual</ns2:view>
1889	            <ns2:maxCaptureEncodings>1</ns2:maxCaptureEncodings>
1890	        </ns2:mediaCapture>
1891	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1892	        xsi:type="ns2:videoCaptureType" captureID="VC7" mediaType="video">
1893	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
1894	            <ns2:nonSpatiallyDefinable>true</ns2:nonSpatiallyDefinable>
1895	            <ns2:content>
1896	                <ns2:captureIDREF>VC3</ns2:captureIDREF>
1897	                <ns2:captureIDREF>VC5</ns2:captureIDREF>
1898	                <ns2:captureIDREF>VC6</ns2:captureIDREF>
1899	            </ns2:content>
1900	            <ns2:composed>true</ns2:composed>
1901	            <ns2:switched>true</ns2:switched>
1902	            <ns2:maxCaptures>1</ns2:maxCaptures>
1903	            <ns2:description lang="en">big picture of the current speaker +
1904	            pips about previous speakers</ns2:description>
1905	            <ns2:priority>1</ns2:priority>
1906	            <ns2:lang>it</ns2:lang>
1907	            <ns2:mobility>static</ns2:mobility>
1908	            <ns2:view>individual</ns2:view>
1909	            <ns2:maxCaptureEncodings>1</ns2:maxCaptureEncodings>
1910	        </ns2:mediaCapture>
1911	    </mediaCaptures>
1912	    <encodingGroups>
1913	        <ns2:encodingGroup encodingGroupID="EG0">
1914	            <ns2:maxGroupBandwidth>600000</ns2:maxGroupBandwidth>
1915	            <ns2:encodingIDList>
1916	                <ns2:encID>ENC1</ns2:encID>
1917	                <ns2:encID>ENC2</ns2:encID>
1918	                <ns2:encID>ENC3</ns2:encID>

1920	            </ns2:encodingIDList>
1921	        </ns2:encodingGroup>
1922	        <ns2:encodingGroup encodingGroupID="EG1">
1923	            <ns2:maxGroupBandwidth>300000</ns2:maxGroupBandwidth>
1924	            <ns2:encodingIDList>
1925	                <ns2:encID>ENC4</ns2:encID>
1926	                <ns2:encID>ENC5</ns2:encID>
1927	            </ns2:encodingIDList>
1928	        </ns2:encodingGroup>
1929	    </encodingGroups>
1930	    <captureScenes>
1931	        <ns2:captureScene scale="unknown" sceneID="CS1">
1932	            <ns2:sceneViews>
1933	                <ns2:sceneView sceneViewID="SE1">
1934	                    <ns2:description lang="en">participants' individual videos
1935	                    </ns2:description>
1936	                    <ns2:mediaCaptureIDs>
1937	                        <ns2:captureIDREF>VC0</ns2:captureIDREF>
1938	                        <ns2:captureIDREF>VC1</ns2:captureIDREF>
1939	                        <ns2:captureIDREF>VC2</ns2:captureIDREF>
1940	                    </ns2:mediaCaptureIDs>
1941	                </ns2:sceneView>
1942	                <ns2:sceneView sceneViewID="SE2">
1943	                    <ns2:description lang="en">loudest segment of the room
1944	                    </ns2:description>
1945	                    <ns2:mediaCaptureIDs>
1946	                        <ns2:captureIDREF>VC3</ns2:captureIDREF>
1947	                    </ns2:mediaCaptureIDs>
1948	                </ns2:sceneView>
1949	                <ns2:sceneView sceneViewID="SE5">
1950	                    <ns2:description lang="en">loudest segment
1951	                    of the room + pips</ns2:description>
1952	                    <ns2:mediaCaptureIDs>
1953	                        <ns2:captureIDREF>VC7</ns2:captureIDREF>
1954	                    </ns2:mediaCaptureIDs>
1955	                </ns2:sceneView>
1956	                <ns2:sceneView sceneViewID="SE4">
1957	                    <ns2:description lang="en">room audio</ns2:description>
1958	                    <ns2:mediaCaptureIDs>
1959	                        <ns2:captureIDREF>AC0</ns2:captureIDREF>
1960	                    </ns2:mediaCaptureIDs>
1961	                </ns2:sceneView>
1962	                <ns2:sceneView sceneViewID="SE3">
1963	                    <ns2:description lang="en">room video</ns2:description>
1964	                    <ns2:mediaCaptureIDs>
1965	                        <ns2:captureIDREF>VC4</ns2:captureIDREF>
1966	                    </ns2:mediaCaptureIDs>
1967	                </ns2:sceneView>

1969	            </ns2:sceneViews>
1970	        </ns2:captureScene>
1971	    </captureScenes>
1972	    <simultaneousSets>
1973	        <ns2:simultaneousSet setID="SS1">
1974	            <ns2:mediaCaptureIDREF>VC7</ns2:mediaCaptureIDREF>
1975	            <ns2:sceneViewIDREF>SE1</ns2:sceneViewIDREF>
1976	        </ns2:simultaneousSet>
1977	        <ns2:simultaneousSet setID="SS2">
1978	            <ns2:mediaCaptureIDREF>VC0</ns2:mediaCaptureIDREF>
1979	            <ns2:mediaCaptureIDREF>VC2</ns2:mediaCaptureIDREF>
1980	            <ns2:mediaCaptureIDREF>VC4</ns2:mediaCaptureIDREF>
1981	            <ns2:mediaCaptureIDREF>VC7</ns2:mediaCaptureIDREF>
1982	        </ns2:simultaneousSet>
1983	    </simultaneousSets>
1984	    <people>
1985	        <ns2:person personID="bob">
1986	            <ns2:personInfo>
1987	                <ns3:fn>
1988	                    <ns3:text>Bob</ns3:text>
1989	                </ns3:fn>
1990	            </ns2:personInfo>
1991	            <ns2:personType>minute taker</ns2:personType>
1992	        </ns2:person>
1993	        <ns2:person personID="alice">
1994	            <ns2:personInfo>
1995	                <ns3:fn>
1996	                    <ns3:text>Alice</ns3:text>
1997	                </ns3:fn>
1998	            </ns2:personInfo>
1999	            <ns2:personType>presenter</ns2:personType>
2000	        </ns2:person>
2001	        <ns2:person personID="ciccio">
2002	            <ns2:personInfo>
2003	                <ns3:fn>
2004	                    <ns3:text>Ciccio</ns3:text>
2005	                </ns3:fn>
2006	            </ns2:personInfo>
2007	            <ns2:personType>chairman</ns2:personType>
2008	            <ns2:personType>timekeeper</ns2:personType>
2009	        </ns2:person>
2010	    </people>
2011	</advertisement>
2012	10.3.  Partial ADV

2014	   In this example, it is first presented a "full" ADV issued by the MP
2015	   to the MC.  The MP describes in the first ADV (sequence number 11) a
2016	   telepresence room with three cameras and associated microphones,
2017	   capturing one participant (Ciccio) from three different point of
2018	   views.  In a second moment, a new participant joins Ciccio in the
2019	   telepresence session, then the MP issues a new ADV to the MC
2020	   (sequence number 12) by exploiting the diff mechanism in order to
2021	   announce the new captured person.

2023	  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
2024	<advertisement xmlns="urn:ietf:params:xml:ns:clue-message"
2025	xmlns:ns2="urn:ietf:params:xml:ns:clue-info"
2026	xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0"
2027	protocol="CLUE" v="0.2">
2028	    <clueId>Ciccio</clueId>
2029	    <sequenceNr>11</sequenceNr>
2030	    <mediaCaptures>
2031	        <ns2:mediaCapture
2032	        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
2033	        xsi:type="ns2:audioCaptureType" captureID="AC0" mediaType="audio">
2034	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
2035	            <ns2:spatialInformation>
2036	                <ns2:capturePoint>
2037	                    <ns2:x>0.5</ns2:x>
2038	                    <ns2:y>1.0</ns2:y>
2039	                    <ns2:z>0.5</ns2:z>
2040	                    <ns2:lineOfCapturePoint>
2041	                        <ns2:x>0.5</ns2:x>
2042	                        <ns2:y>0.0</ns2:y>
2043	                        <ns2:z>0.5</ns2:z>
2044	                    </ns2:lineOfCapturePoint>
2045	                </ns2:capturePoint>
2046	            </ns2:spatialInformation>
2047	            <ns2:individual>true</ns2:individual>
2048	            <ns2:encGroupIDREF>EG1</ns2:encGroupIDREF>
2049	            <ns2:description lang="en">main audio from the room
2050	            </ns2:description>
2051	            <ns2:priority>1</ns2:priority>
2052	            <ns2:lang>it</ns2:lang>
2053	            <ns2:mobility>static</ns2:mobility>
2054	            <ns2:view>room</ns2:view>
2055	            <ns2:capturedPeople>
2056	                <ns2:personIDREF>ciccio</ns2:personIDREF>

2058	            </ns2:capturedPeople>
2059	            <ns2:maxCaptureEncodings>1</ns2:maxCaptureEncodings>
2060	        </ns2:mediaCapture>
2061	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
2062	        xsi:type="ns2:videoCaptureType" captureID="VC0" mediaType="video">
2063	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
2064	            <ns2:spatialInformation>
2065	                <ns2:capturePoint>
2066	                    <ns2:x>0.5</ns2:x>
2067	                    <ns2:y>1.0</ns2:y>
2068	                    <ns2:z>0.5</ns2:z>
2069	                    <ns2:lineOfCapturePoint>
2070	                        <ns2:x>0.5</ns2:x>
2071	                        <ns2:y>0.0</ns2:y>
2072	                        <ns2:z>0.5</ns2:z>
2073	                    </ns2:lineOfCapturePoint>
2074	                </ns2:capturePoint>
2075	            </ns2:spatialInformation>
2076	            <ns2:individual>true</ns2:individual>
2077	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
2078	            <ns2:description lang="en">left camera video capture
2079	            </ns2:description>
2080	            <ns2:priority>1</ns2:priority>
2081	            <ns2:lang>it</ns2:lang>
2082	            <ns2:mobility>static</ns2:mobility>
2083	            <ns2:view>individual</ns2:view>
2084	            <ns2:capturedPeople>
2085	                <ns2:personIDREF>ciccio</ns2:personIDREF>
2086	            </ns2:capturedPeople>
2087	            <ns2:maxCaptureEncodings>2</ns2:maxCaptureEncodings>
2088	        </ns2:mediaCapture>
2089	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
2090	        xsi:type="ns2:videoCaptureType" captureID="VC1" mediaType="video">
2091	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
2092	            <ns2:spatialInformation>
2093	                <ns2:capturePoint>
2094	                    <ns2:x>0.5</ns2:x>
2095	                    <ns2:y>1.0</ns2:y>
2096	                    <ns2:z>0.5</ns2:z>
2097	                    <ns2:lineOfCapturePoint>
2098	                        <ns2:x>0.5</ns2:x>
2099	                        <ns2:y>0.0</ns2:y>
2100	                        <ns2:z>0.5</ns2:z>
2101	                    </ns2:lineOfCapturePoint>
2102	                </ns2:capturePoint>
2103	            </ns2:spatialInformation>
2104	            <ns2:individual>true</ns2:individual>
2105	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
2106	            <ns2:description lang="en">central camera video capture
2107	            </ns2:description>
2108	            <ns2:priority>1</ns2:priority>
2109	            <ns2:lang>it</ns2:lang>
2110	            <ns2:mobility>static</ns2:mobility>
2111	            <ns2:view>individual</ns2:view>
2112	            <ns2:capturedPeople>
2113	                <ns2:personIDREF>ciccio</ns2:personIDREF>
2114	            </ns2:capturedPeople>
2115	            <ns2:maxCaptureEncodings>2</ns2:maxCaptureEncodings>
2116	        </ns2:mediaCapture>
2117	        <ns2:mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
2118	        xsi:type="ns2:videoCaptureType" captureID="VC2" mediaType="video">
2119	            <ns2:captureSceneIDREF>CS1</ns2:captureSceneIDREF>
2120	            <ns2:spatialInformation>
2121	                <ns2:capturePoint>
2122	                    <ns2:x>0.5</ns2:x>
2123	                    <ns2:y>1.0</ns2:y>
2124	                    <ns2:z>0.5</ns2:z>
2125	                    <ns2:lineOfCapturePoint>
2126	                        <ns2:x>0.5</ns2:x>
2127	                        <ns2:y>0.0</ns2:y>
2128	                        <ns2:z>0.5</ns2:z>
2129	                    </ns2:lineOfCapturePoint>
2130	                </ns2:capturePoint>
2131	            </ns2:spatialInformation>
2132	            <ns2:individual>true</ns2:individual>
2133	            <ns2:encGroupIDREF>EG0</ns2:encGroupIDREF>
2134	            <ns2:description lang="en">right camera video capture
2135	            </ns2:description>
2136	            <ns2:priority>1</ns2:priority>
2137	            <ns2:lang>it</ns2:lang>
2138	            <ns2:mobility>static</ns2:mobility>
2139	            <ns2:view>individual</ns2:view>
2140	            <ns2:capturedPeople>
2141	                <ns2:personIDREF>ciccio</ns2:personIDREF>
2142	            </ns2:capturedPeople>
2143	            <ns2:maxCaptureEncodings>2</ns2:maxCaptureEncodings>
2144	        </ns2:mediaCapture>
2145	    </mediaCaptures>
2146	    <encodingGroups>
2147	        <ns2:encodingGroup encodingGroupID="EG0">
2148	            <ns2:maxGroupBandwidth>600000</ns2:maxGroupBandwidth>
2149	            <ns2:encodingIDList>
2150	                <ns2:encID>ENC1</ns2:encID>
2151	                <ns2:encID>ENC2</ns2:encID>
2152	                <ns2:encID>ENC3</ns2:encID>
2153	            </ns2:encodingIDList>

2155	        </ns2:encodingGroup>
2156	        <ns2:encodingGroup encodingGroupID="EG1">
2157	            <ns2:maxGroupBandwidth>300000</ns2:maxGroupBandwidth>
2158	            <ns2:encodingIDList>
2159	                <ns2:encID>ENC4</ns2:encID>
2160	                <ns2:encID>ENC5</ns2:encID>
2161	            </ns2:encodingIDList>
2162	        </ns2:encodingGroup>
2163	    </encodingGroups>
2164	    <captureScenes>
2165	        <ns2:captureScene scale="unknown" sceneID="CS1">
2166	            <ns2:sceneViews>
2167	                <ns2:sceneView sceneViewID="SE1">
2168	                    <ns2:mediaCaptureIDs>
2169	                        <ns2:captureIDREF>VC0</ns2:captureIDREF>
2170	                        <ns2:captureIDREF>VC1</ns2:captureIDREF>
2171	                        <ns2:captureIDREF>VC2</ns2:captureIDREF>
2172	                    </ns2:mediaCaptureIDs>
2173	                </ns2:sceneView>
2174	                <ns2:sceneView sceneViewID="SE4">
2175	                    <ns2:mediaCaptureIDs>
2176	                        <ns2:captureIDREF>AC0</ns2:captureIDREF>
2177	                    </ns2:mediaCaptureIDs>
2178	                </ns2:sceneView>
2179	            </ns2:sceneViews>
2180	        </ns2:captureScene>
2181	    </captureScenes>
2182	    <simultaneousSets>
2183	        <ns2:simultaneousSet setID="SS1">
2184	            <ns2:sceneViewIDREF>SE1</ns2:sceneViewIDREF>
2185	        </ns2:simultaneousSet>
2186	        <ns2:simultaneousSet setID="SS2">
2187	            <ns2:mediaCaptureIDREF>AC0</ns2:mediaCaptureIDREF>
2188	        </ns2:simultaneousSet>
2189	    </simultaneousSets>
2190	    <people>
2191	        <ns2:person personID="ciccio">
2192	            <ns2:personInfo>
2193	                <ns3:fn>
2194	                    <ns3:text>Ciccio Esposito</ns3:text>
2195	                </ns3:fn>
2196	            </ns2:personInfo>
2197	            <ns2:personType>chairman</ns2:personType>
2198	            <ns2:personType>timekeeper</ns2:personType>
2199	        </ns2:person>
2200	    </people>
2201	</advertisement>
2202	<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
2203	<advertisement xmlns="urn:ietf:params:xml:ns:clue-message"
2204	xmlns:ns2="urn:ietf:params:xml:ns:clue-info"
2205	xmlns:ns3="urn:ietf:params:xml:ns:vcard-4.0"
2206	protocol="CLUE" v="0.2">
2207	    <clueId>Ciccio</clueId>
2208	    <sequenceNr>12</sequenceNr>
2209	    <add sel="/advertisement/people">
2210	       <ns2:person personID="alice_ID">
2211	           <ns2:personInfo>
2212	               <ns3:fn>
2213	                   <ns3:text>Alice Romano</ns3:text>
2214	               </ns3:fn>
2215	           </ns2:personInfo>
2216	           <ns2:personType>attendee</ns2:personType>
2217	       </ns2:person>
2218	    </add>
2219	    <add sel="/advertisement/mediaCaptures/mediaCapture/capturedPeople">
2220	        <ns2:personIDREF>alice_ID</ns2:personIDREF>
2221	    </add>
2222	</advertisement>

2224	11.  IANA Considerations

2226	   This document registers a new XML namespace, a new XML schema and the
2227	   MIME type for the schema.  This document also registers the "CLUE"
2228	   Application Service tag and the "CLUE" Application Protocol tag and
2229	   defines registries for the CLUE messages and response codes.

2231	11.1.  URN Sub-Namespace Registration

2233	   This section registers a new XML namespace,
2234	   ""urn:ietf:params:xml:ns:clue-protocol"".

2236	   URI: urn:ietf:params:xml:ns:clue-protocol

2238	   Registrant Contact: IETF CLUE working group (clue@ietf.org), Simon
2239	   Pietro Romano (spromano@unina.it).

2241	   XML:

2243	   BEGIN
2244	    <?xml version="1.0"?>
2245	    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
2246	      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
2247	    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
2248	      <head>
2249	        <title>CLUE Messages</title>
2250	      </head>
2251	      <body>
2252	        <h1>Namespace for CLUE Messages</h1>
2253	        <h2>urn:ietf:params:xml:ns:clue-protocol</h2>
2254	   [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
2255	       with the RFC number for this specification.]]
2256	        <p>See <a href="[[RFC URL]]">
2257	           RFCXXXX</a>.</p>
2258	      </body>
2259	    </html>
2260	   END

2262	11.2.  XML Schema registration

2264	   This section registers an XML schema per the guidelines in [RFC3688].

2266	   URI: urn:ietf:params:xml:schema:clue-protocol

2268	   Registrant Contact: CLUE working group (clue@ietf.org), Simon Pietro
2269	   Romano (spromano@unina.it).

2271	   Schema: The XML for this schema can be found as the entirety of
2272	   Section 9 of this document.

2274	11.3.  MIME Media Type Registration for 'application/clue+xml'

2276	   This section registers the " "application/clue+xml"" MIME type.

2278	   To: ietf-types@iana.org

2280	   Subject: Registration of MIME media type application/clue+xml

2282	   MIME media type name: application

2284	   MIME subtype name: clue+xml

2286	   Required parameters: (none)

2288	   Optional parameters: charset
2289	   Same as the charset parameter of "application/xml" as specified in

2291	   [RFC3023], Section 3.2.

2293	   Encoding considerations: Same as the encoding considerations of
2294	   "application/xml" as specified in [RFC3023], Section 3.2.

2296	   Security considerations: This content type is designed to carry
2297	   protocol data related to telepresence session control.  Some of the
2298	   data could be considered private.  This media type does not provide
2299	   any protection and thus other mechanisms such as those described in
2300	   Section Security are required to protect the data.  This media type
2301	   does not contain executable content.

2303	   Interoperability considerations: None.

2305	   Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
2306	   replace XXXX with the RFC number for this specification.]]

2308	   Applications that use this media type: CLUE participants.

2310	   Additional Information: Magic Number(s): (none),
2311	   File extension(s): .clue,
2312	   Macintosh File Type Code(s): TEXT.

2314	   Person & email address to contact for further information: Simon
2315	   Pietro Romano (spromano@unina.it).

2317	   Intended usage: LIMITED USE

2319	   Author/Change controller: The IETF

2321	   Other information: This media type is a specialization of
2322	   application/xml [RFC3023], and many of the considerations described
2323	   there also apply to application/clue+xml.

2325	11.4.  DNS Registrations

2327	   Section 11.4.1 defines an Application Service tag of "CLUE", which is
2328	   used to identify the CLUE service.  The Application Protocol tag
2329	   "CLUE", defined in Section 11.4.2, is used to identify a CLUE
2330	   Participant that understands CLUE.

2332	11.4.1.  Application Service tag

2334	   This section registers a new S-NAPTR/U-NAPTR Application Service tag
2335	   for CLUE, as mandated by [RFC3958].

2337	   Application Service Tag: CLUE
2338	   Intended usage: Identifies a server that supports CLUE telepresence
2339	   conferencing.

2341	   Defining publication: RFCXXXX [[NOTE TO IANA/RFC-EDITOR: Please
2342	   replace XXXX with the RFC number for this specification.]]

2344	   Contact information: The authors of this document

2346	   Author/Change controller: The IESG

2348	11.4.2.  Application Protocol tag

2350	   This section registers a new S-NAPTR/U-NAPTR Application Protocol tag
2351	   for CLUE, as mandated by [RFC3958].

2353	   Application Service Tag: CLUE

2355	   Intended Usage: Identifies the CLUE Protocol.

2357	   Applicable Service Tag(s): CLUE

2359	   Terminal NAPTR Record Type(s): U

2361	   Defining Publication: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please
2362	   replace XXXX with the RFC number for this specification.]]

2364	   Contact Information: The authors of this document

2366	   Author/Change Controller: The IESG

2368	11.5.  CLUE Protocol Registry

2370	   The document requests that the IANA creates new registries for CLUE
2371	   messages and response codes.

2373	11.5.1.  CLUE Message Types

2375	   The following summarizes the registry for CLUE messages:

2377	   Related Registry: CLUE Message Types Registry

2379	   Defining RFC: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX
2380	   with the RFC number for this specification.]]

2382	   Registration/Assignment Procedures: Following the policies outlined
2383	   in [RFC5226], the IANA policy for assigning new values for the CLUE
2384	   message types for the CLUE protocol is Specification Required.

2386	   Registrant Contact: IETF CLUE working group (clue@ietf.org), Simon
2387	   Pietro Romano (spromano@unina.it).

2389	   The initial Message table is populated using the CLUE messages
2390	   described in Section 4 and defined in the XML schema in Section 9.

2392	   ToDo: table: message description reference

2394	11.5.2.  CLUE Response Codes

2396	   The following summarizes the requested registry for CLUE response
2397	   codes:

2399	   Related Registry: CLUE Response Code Registry

2401	   Defining RFC: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX
2402	   with the RFC number for this specification.]]

2404	   Registration/Assignment Procedures: Following the policies outlined
2405	   in [RFC5226], the IANA policy for assigning new values for the
2406	   Response codes for CLUE shall be Specification Required.

2408	   Registrant Contact: IETF CLUE working group (clue@ietf.org), Simon
2409	   Pietro Romano (spromano@unina.it).

2411	   The initial Response-code table is populated using the Response codes
2412	   defined in Section 4.7 as follows:

2414	   ToDo: table: number, default response string, description, reference

2416	12.  Diff with draft-ietf-clue-protocol-01

2418	   o  The diff mechanism for the ADV message has been introduced.

2420	   o  READV and READV RESPONSE message have been both removed.

2422	   o  The state machines have been deeply reviewed and changed.

2424	   o  References: references have been updated and splitted into
2425	      Informative references and Normative references as in framework
2426	      v17.

2428	   o  Schema: <globalSceneEntries> changed in <globalViews>,
2429	      <participants> in <people>

2431	   o  Terminology: many definitions added.

2433	   o  Response codes updated.

2435	13.  Diff with draft-ietf-clue-protocol-00

2437	   1.  The XML schema of the ADVERTISEMENT and of the READV have been
2438	       aligned with the current definitions in
2439	       [I-D.ietf-clue-data-model-schema] (example of updates:
2440	       <participants> --> <people>, <globalCaptureEntries> -->
2441	       <globalSceneEntries>)

2443	   2.  Text has been added to clarify that, in the OPTIONS RESPONSE,
2444	       when the response code is not an error response code, both
2445	       <mediaProvider> and <mediaConsumer> are mandatory.

2447	   3.  The content of the "v" attribute and of the <version> elements
2448	       carried in the OPTIONS and OPTIONS RESPONSE messages has been
2449	       described more precisely.

2451	   4.  Advertisement examples have been added.

2453	14.  Diff with draft-presta-clue-protocol-04

2455	   1.  The response code type error in the OPTIONS response (and in
2456	       other parts) has been corrected.

2458	15.  Diff with draft-presta-clue-protocol-03

2460	   1.  The XML Schema has been deeply revised and completed.

2462	   2.  The descriptions of the CLUE messages have been added.

2464	   3.  The distinction between major version numbers and minor version
2465	       numbers has been cut and pasted from [I-D.ietf-clue-signaling].

2467	   4.  Besides the two way one, a three way mechanism for the options
2468	       negotiation has been proposed and provided to foster discussion.

2470	16.  Diff with draft-presta-clue-protocol-02

2472	   1.  "Terminology" section added.

2474	   2.  Introduced the concept of "CLUE Participant" - an Endpoint or a
2475	       MCU able to use the CLUE protocol within a telepresence session.
2476	       A CLUE Participant can act as a Media Provider and/or as a Media
2477	       Consumer.

2479	   3.  Introduced the ACK/NACK mechanism for the ADVERTISEMENT.

2481	   4.  MP and MC state machines have been updated.  The CP state machine
2482	       has been added.

2484	17.  Acknowledgments

2486	   The authors thank all the CLUErs for their precious feedbacks and
2487	   support, in particular Paul Kyzivat, Christian Groves and Scarlett
2488	   Liuyan.

2490	18.  References

2492	18.1.  Normative References

2494	   [I-D.ietf-clue-data-model-schema]          Presta, R. and S. Romano,
2495	                                              "An XML Schema for the
2496	                                              CLUE data model", draft-
2497	                                              ietf-clue-data-model-
2498	                                              schema-07 (work in
2499	                                              progress), September 2014.

2501	   [I-D.ietf-clue-datachannel]                Holmberg, C., "CLUE
2502	                                              Protocol Data Channel", dr
2503	                                              aft-ietf-clue-datachannel-
2504	                                              01 (work in progress),
2505	                                              September 2014.

2507	   [I-D.ietf-clue-framework]                  Duckworth, M., Pepperell,
2508	                                              A., and S. Wenger,
2509	                                              "Framework for
2510	                                              Telepresence Multi-
2511	                                              Streams", draft-ietf-clue-
2512	                                              framework-17 (work in
2513	                                              progress), September 2014.

2515	   [I-D.ietf-clue-signaling]                  Kyzivat, P., Xiao, L.,
2516	                                              Groves, C., and R. Hansen,
2517	                                              "CLUE Signaling", draft-
2518	                                              ietf-clue-signaling-03
2519	                                              (work in progress),
2520	                                              August 2014.

2522	   [RFC3023]                                  Murata, M., St. Laurent,
2523	                                              S., and D. Kohn, "XML
2524	                                              Media Types", RFC 3023,
2525	                                              January 2001.

2527	   [RFC3550]                                  Schulzrinne, H., Casner,
2528	                                              S., Frederick, R., and V.

2530	                                              Jacobson, "RTP: A
2531	                                              Transport Protocol for
2532	                                              Real-Time Applications",
2533	                                              STD 64, RFC 3550,
2534	                                              July 2003.

2536	   [RFC3688]                                  Mealling, M., "The IETF
2537	                                              XML Registry", BCP 81,
2538	                                              RFC 3688, January 2004.

2540	   [RFC3958]                                  Daigle, L. and A. Newton,
2541	                                              "Domain-Based Application
2542	                                              Service Location Using SRV
2543	                                              RRs and the Dynamic
2544	                                              Delegation Discovery
2545	                                              Service (DDDS)", RFC 3958,
2546	                                              January 2005.

2548	   [RFC5226]                                  Narten, T. and H.
2549	                                              Alvestrand, "Guidelines
2550	                                              for Writing an IANA
2551	                                              Considerations Section in
2552	                                              RFCs", BCP 26, RFC 5226,
2553	                                              May 2008.

2555	   [RFC5261]                                  Urpalainen, J., "An
2556	                                              Extensible Markup Language
2557	                                              (XML) Patch Operations
2558	                                              Framework Utilizing XML
2559	                                              Path Language (XPath)
2560	                                              Selectors", RFC 5261,
2561	                                              September 2008.

2563	18.2.  Informative References

2565	   [I-D.groves-clue-partial-update]           Groves, C., Yang, W., and
2566	                                              R. Even, "CLUE Partial
2567	                                              Updates", draft-groves-
2568	                                              clue-partial-update-00
2569	                                              (work in progress),
2570	                                              September 2014.

2572	   [I-D.ietf-clue-telepresence-requirements]  Romanow, A., Botzko, S.,
2573	                                              and M. Barnes,
2574	                                              "Requirements for
2575	                                              Telepresence Multi-
2576	                                              Streams", draft-ietf-clue-
2577	                                              telepresence-requirements-
2578	                                              07 (work in progress),
2579	                                              December 2013.

2581	   [RFC4353]                                  Rosenberg, J., "A
2582	                                              Framework for Conferencing
2583	                                              with the Session
2584	                                              Initiation Protocol
2585	                                              (SIP)", RFC 4353,
2586	                                              February 2006.

2588	   [RFC5117]                                  Westerlund, M. and S.
2589	                                              Wenger, "RTP Topologies",
2590	                                              RFC 5117, January 2008.

2592	   [RFC6502]                                  Camarillo, G., Srinivasan,
2593	                                              S., Even, R., and J.
2594	                                              Urpalainen, "Conference
2595	                                              Event Package Data Format
2596	                                              Extension for Centralized
2597	                                              Conferencing (XCON)",
2598	                                              RFC 6502, March 2012.

2600	   [RFC6503]                                  Barnes, M., Boulton, C.,
2601	                                              Romano, S., and H.
2602	                                              Schulzrinne, "Centralized
2603	                                              Conferencing Manipulation
2604	                                              Protocol", RFC 6503,
2605	                                              March 2012.

2607	Authors' Addresses

2609	   Roberta Presta
2610	   University of Napoli
2611	   Via Claudio 21
2612	   Napoli  80125
2613	   Italy

2615	   EMail: roberta.presta@unina.it

2617	   Simon Pietro Romano
2618	   University of Napoli
2619	   Via Claudio 21
2620	   Napoli  80125
2621	   Italy

2623	   EMail: spromano@unina.it