CLUE Working Group R. Presta Internet-Draft S P. Romano Intended status: Standards Track University of Napoli Expires: April 21, 2016 October 19, 2015 An XML Schema for the CLUE data model draft-ietf-clue-data-model-schema-11 Abstract This document provides an XML schema file for the definition of CLUE data model types. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 21, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents Presta & Romano Expires April 21, 2016 [Page 1] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. . . . . . . . . . . . . . . . . . . . . . . . 17 6. . . . . . . . . . . . . . . . . . . . . . . . 17 7. . . . . . . . . . . . . . . . . . . . . . . . 18 8. . . . . . . . . . . . . . . . . . . . . . . 18 9. . . . . . . . . . . . . . . . . . . . . . . . . 18 10. . . . . . . . . . . . . . . . . . . . . . . 18 11. . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. captureID attribute . . . . . . . . . . . . . . . . . . . 19 11.2. mediaType attribute . . . . . . . . . . . . . . . . . . . 20 11.3. . . . . . . . . . . . . . . . . . . . 20 11.4. . . . . . . . . . . . . . . . . . . . . . 20 11.5. . . . . . . . . . . . . . . . . . . 20 11.5.1. . . . . . . . . . . . . . . . . . . . 21 11.5.2. . . . . . . . . . . . . . . . . . . . . 22 11.6. . . . . . . . . . . . . . . . . . 23 11.7. . . . . . . . . . . . . . . . . . . . . . . . . 23 11.8. . . . . . . . . . . . . . . . . . . . 24 11.9. . . . . . . . . . . . . . . . . . . . 24 11.10. . . . . . . . . . . . . . . . . . . . . . . . . 24 11.11. . . . . . . . . . . . . . . . . . . . . . . 25 11.12. . . . . . . . . . . . . . . . . . . . . . . 26 11.13. . . . . . . . . . . . . . . . . . . . . . . 26 11.14. . . . . . . . . . . . . . . . . . . . . . . . 27 11.15. . . . . . . . . . . . . . . . . . . . . . . . . . 27 11.16. . . . . . . . . . . . . . . . . . . . . . . . 27 11.17. . . . . . . . . . . . . . . . . . . . . . . . 27 11.18. . . . . . . . . . . . . . . . . . . . . . . . . . 28 11.19. . . . . . . . . . . . . . . . . . . . . . 28 11.19.1. . . . . . . . . . . . . . . . . . . . 28 11.19.2. . . . . . . . . . . . . . . . . . . 29 11.20. Audio captures . . . . . . . . . . . . . . . . . . . . . 29 11.20.1. . . . . . . . . . . . . . . . . 30 11.21. Video captures . . . . . . . . . . . . . . . . . . . . . 30 11.22. Text captures . . . . . . . . . . . . . . . . . . . . . . 31 11.23. Other capture types . . . . . . . . . . . . . . . . . . . 31 11.24. . . . . . . . . . . . . . . . . . . . . . 32 11.24.1. . . . . . . . . . . . . . . . . . 33 11.24.2. . . . . . . . . . . . . . . . . . . . . 33 11.24.3. sceneID attribute . . . . . . . . . . . . . . . . . . 33 11.24.4. scale attribute . . . . . . . . . . . . . . . . . . . 33 11.25. . . . . . . . . . . . . . . . . . . . . . . . 34 11.25.1. . . . . . . . . . . . . . . . . . . 35 11.25.2. sceneViewID attribute . . . . . . . . . . . . . . . . 35 11.26. . . . . . . . . . . . . . . . . . . . . . 35 Presta & Romano Expires April 21, 2016 [Page 2] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 11.26.1. . . . . . . . . . . . . . . . . . 36 11.26.2. . . . . . . . . . . . . . . . . . . 36 11.26.3. encodingGroupID attribute . . . . . . . . . . . . . . 36 11.27. . . . . . . . . . . . . . . . . . . . . 36 11.27.1. setID attribute . . . . . . . . . . . . . . . . . . . 37 11.27.2. mediaType attribute . . . . . . . . . . . . . . . . . 37 11.27.3. . . . . . . . . . . . . . . . . . 38 11.27.4. . . . . . . . . . . . . . . . . . . 38 11.27.5. . . . . . . . . . . . . . . . . . 38 11.28. . . . . . . . . . . . . . . . . . . . . . . 38 11.29. . . . . . . . . . . . . . . . . . . . . . . . . 38 11.29.1. . . . . . . . . . . . . . . . . . . . . . . 39 12. . . . . . . . . . . . . . . . . . . . . . . 40 12.1. . . . . . . . . . . . . . . . . . . . . . . . 41 12.2. . . . . . . . . . . . . . . . . . . . . . . 41 12.3. . . . . . . . . . . . . . . . . . . . 41 13. . . . . . . . . . . . . . . . . . . . . . . . . . . 41 14. XML Schema extensibility . . . . . . . . . . . . . . . . . . . 42 14.1. Example of extension . . . . . . . . . . . . . . . . . . 43 15. Security considerations . . . . . . . . . . . . . . . . . . . 44 16. IANA considerations . . . . . . . . . . . . . . . . . . . . . 45 16.1. XML namespace registration . . . . . . . . . . . . . . . 45 16.2. XML Schema registration . . . . . . . . . . . . . . . . . 46 16.3. MIME Media Type Registration for 'application/clue_info+xml' . . . . . . . . . . . . . . . 46 17. Sample XML file . . . . . . . . . . . . . . . . . . . . . . . 47 18. MCC example . . . . . . . . . . . . . . . . . . . . . . . . . 54 19. Diff with draft-ietf-clue-data-model-schema-10 version . . . . 60 20. Diff with draft-ietf-clue-data-model-schema-09 version . . . . 61 21. Diff with draft-ietf-clue-data-model-schema-08 version . . . . 61 22. Diff with draft-ietf-clue-data-model-schema-07 version . . . . 61 23. Diff with draft-ietf-clue-data-model-schema-06 version . . . . 61 24. Diff with draft-ietf-clue-data-model-schema-04 version . . . . 62 25. Diff with draft-ietf-clue-data-model-schema-03 version . . . . 63 26. Diff with draft-ietf-clue-data-model-schema-02 version . . . . 63 27. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63 28. Informative References . . . . . . . . . . . . . . . . . . . . 63 Presta & Romano Expires April 21, 2016 [Page 3] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 1. Introduction This document provides an XML schema file for the definition of CLUE data model types. The schema is based on information contained in [I-D.ietf-clue-framework]. It encodes information and constraints defined in the aforementioned document in order to provide a formal representation of the concepts therein presented. The document aims at the definition of a coherent structure for information associated with the description of a telepresence scenario. Such information is used within the CLUE protocol messages ([I-D.ietf-clue-protocol]) enabling the dialogue between a Media Provider and a Media Consumer. CLUE protocol messages, indeed, are XML messages allowing (i) a Media Provider to advertise its telepresence capabilities in terms of media captures, capture scenes, and other features envisioned in the CLUE framework, according to the format herein defined and (ii) a Media Consumer to request the desired telepresence options in the form of capture encodings, represented as described in this document. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Definitions This document refers to the same definitions used in [I-D.ietf-clue-framework], except for the "CLUE Participant" definition. We briefly recall herein some of the main terms used in the document. Audio Capture: Media Capture for audio. Denoted as ACn in the examples in this document. Capture: Same as Media Capture. Capture Device: A device that converts physical input, such as audio, video or text, into an electrical signal, in most cases to be fed into a media encoder. Capture Encoding: A specific encoding of a Media Capture, to be sent by a Media Provider to a Media Consumer via RTP. Presta & Romano Expires April 21, 2016 [Page 4] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 Capture Scene: A structure representing a spatial region captured by one or more Capture Devices, each capturing media representing a portion of the region. The spatial region represented by a Capture Scene MAY correspond to a real region in physical space, such as a room. A Capture Scene includes attributes and one or more Capture Scene Views, with each view including one or more Media Captures. Capture Scene View: A list of Media Captures of the same media type that together form one way to represent the entire Capture Scene.. CLUE Participant: This term is not imported from the framework terminology. A CLUE Participant identifies a generic entity (either an Endpoint or a MCU) making use of the CLUE protocol. Consumer: Short for Media Consumer. Encoding or Individual Encoding: A set of parameters representing a way to encode a Media Capture to become a Capture Encoding. Encoding Group: A set of encoding parameters representing a total media encoding capability to be sub-divided across potentially multiple Individual Encodings. Endpoint A CLUE-capable device which is the logical point of final termination through receiving, decoding and rendering, and/or initiation through capturing, encoding, and sending of media streams. An endpoint consists of one or more physical devices which source and sink media streams, and exactly one [RFC4353] Participant (which, in turn, includes exactly one SIP User Agent). Endpoints can be anything from multiscreen/multicamera rooms to handheld devices. Media: Any data that, after suitable encoding, can be conveyed over RTP, including audio, video or timed text. Media Capture: A source of Media, such as from one or more Capture Devices or constructed from other Media streams. Media Consumer: A CLUE-capable device that intends to receive Capture Encodings. Media Provider: A CLUE-capable device that intends to send Capture Encodings. Presta & Romano Expires April 21, 2016 [Page 5] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 Multiple Content Capture: A Capture that mixes and/or switches other Captures of a single type. (E.g. all audio or all video.) Particular Media Captures may or may not be present in the resultant Capture Encoding depending on time or space. Denoted as MCCn in the example cases in this document. Multipoint Control Unit (MCU): A CLUE-capable device that connects two or more endpoints together into one single multimedia conference [RFC5117]. An MCU includes an [RFC4353] like Mixer, without the [RFC4353] requirement to send media to each participant. Plane of Interest: The spatial plane containing the most relevant Subject matter. Provider: Same as Media Provider. Render: The process of reproducing the received Streams like, for instance, displaying of the remote video on the Media Consumer's screens, or playing of the remote audio through loudspeakers. Scene: Same as Capture Scene. Simultaneous Transmission Set: A set of Media Captures that can be transmitted simultaneously from a Media Provider. Single Media Capture: A capture which contains media from a single source capture device, e.g. an audio capture from a single microphone, a video capture from a single camera. Spatial Relation: The arrangement in space of two objects, in contrast to relation in time or other relationships. Stream: A Capture Encoding sent from a Media Provider to a Media Consumer via RTP [RFC3550]. Stream Characteristics: The union of the features used to describe a Stream in the CLUE environment and in the SIP-SDP environment. Video Capture: A Media Capture for video. 4. XML Schema This section contains the CLUE data model schema definition. The element and attribute definitions are formal representations of the concepts needed to describe the capabilities of a Media Provider and the streams that are requested by a Media Consumer given the Presta & Romano Expires April 21, 2016 [Page 6] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 Media Provider's ADVERTISEMENT ([I-D.ietf-clue-protocol]). The main groups of information are: : the list of media captures available (Section 5) : the list of encoding groups (Section 6) : the list of capture scenes (Section 7) : the list of simultaneous transmission sets (Section 8) : the list of global views sets (Section 9) : meta data about the participants represented in the telepresence session (Section 11.29). : the list of instantiated capture encodings (Section 10) All of the above refers to concepts that have been introduced in [I-D.ietf-clue-framework] and further detailed in this document. Presta & Romano Expires April 21, 2016 [Page 7] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 Presta & Romano Expires April 21, 2016 [Page 8] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 Presta & Romano Expires April 21, 2016 [Page 9] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 Presta & Romano Expires April 21, 2016 [Page 10] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 Presta & Romano Expires April 21, 2016 [Page 11] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 Presta & Romano Expires April 21, 2016 [Page 12] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 Presta & Romano Expires April 21, 2016 [Page 13] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 Presta & Romano Expires April 21, 2016 [Page 14] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 Presta & Romano Expires April 21, 2016 [Page 15] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 Presta & Romano Expires April 21, 2016 [Page 16] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 Following sections describe the XML schema in more detail. As a general remark, please notice that optional elements that don't define what their absence means are intended to be associated with undefined properties. 5. represents the list of one or more media captures available at the Media Provider's side. Each media capture is represented by a element (Section 11). 6. represents the list of the encoding groups organized on the Media Provider's side. Each encoding group is represented by an element (Section 11.26). Presta & Romano Expires April 21, 2016 [Page 17] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 7. represents the list of the capture scenes organized on the Media Provider's side. Each capture scene is represented by a element. (Section 11.24). 8. contains the simultaneous sets indicated by the Media Provider. Each simultaneous set is represented by a element. (Section 11.27). 9. contains a set of alternative representations of all the scenes that are offered by a Media Provider to a Media Consumer. Each alternative is named "global view" and it is represented by a element. (Section 11.28). 10. is a list of capture encodings. It can represent the list of the desired capture encodings indicated by the Media Consumer or the list of instantiated captures on the provider's side. Each capture encoding is represented by a element. (Section 12). 11. A Media Capture is the fundamental representation of a media flow that is available on the provider's side. Media captures are characterized (i) by a set of features that are independent from the specific type of medium, and (ii) by a set of features that are media-specific. The features that are common to all media types appear within the media capture type, that has been designed as an abstract complex type. Media-specific captures, such as video captures, audio captures and others, are specializations of that abstract media capture type, as in a typical generalization- specialization hierarchy. The following is the XML Schema definition of the media capture type: Presta & Romano Expires April 21, 2016 [Page 18] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 11.1. captureID attribute The "captureID" attribute is a mandatory field containing the identifier of the media capture. Such an identifier serves as the way the capture is referenced from other data model elements (e.g., simultaneous sets, capture encodings, and others). Presta & Romano Expires April 21, 2016 [Page 19] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 11.2. mediaType attribute The "mediaType" attribute is a mandatory attribute specifying the media type of the capture. Common values are "audio", "video", "text". Other values can be provided. It is assumed that implementations agree on the interpretation of those other values. 11.3. is a mandatory field containing the value of the identifier of the capture scene the media capture is defined in, i.e., the value of the sceneID (Section 11.24.3) attribute of that capture scene. Indeed, each media capture must be defined within one and only one capture scene. When a media capture is spatially definable, some spatial information is provided along with it in the form of point coordinates (see Section 11.5). Such coordinates refer to the space of coordinates defined for the capture scene containing the capture. 11.4. is an optional field containing the identifier of the encoding group the media capture is associated with, i.e., the value of the encodingGroupID (Section 11.26.3) attribute of that encoding group. Media captures that are not associated with any encoding group can not be instantiated as media streams. 11.5. Media captures are divided into two categories: (i) non spatially definable captures and (ii) spatially definable captures. Captures are spatially definable when at least (i) it is possible to provide the coordinates of the device position within the telepresence room of origin (capture point) together with its capturing direction specified by a second point (point on line of capture), or (ii) it is possible to provide the represented area within the telepresence room, by listing the coordinates of the four co-planar points identifying the plane of interest (area of capture). The coordinates of the abovementioned points must be expressed according to the coordinate space of the capture scene the media captures belongs to. Non spatially definable captures cannot be characterized within the physical space of the telepresence room of origin. Captures of this kind are for example those related to recordings, text captures, DVDs, registered presentations, or external streams that are played in the telepresence room and transmitted to remote sites. Presta & Romano Expires April 21, 2016 [Page 20] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 Spatially definable captures represent a part of the telepresence room. The captured part of the telepresence room is described by means of the element. By comparing the element of different media captures within the same capture scene, a consumer can better determine the spatial relationships between them and render them correctly. Non spatially definable captures do not embed such element in their XML description: they are instead characterized by having the tag set to "true" (see Section 11.6). The definition of the spatial information type is the following: The contains the coordinates of the capture device that is taking the capture (i.e., the capture point), as well as, optionally, the pointing direction (i.e., the point on line of capture) (see Section 11.5.1). The is an optional field containing four points defining the captured area covered by the capture (see Section 11.5.2). The scale of the points coordinates is specified in the scale (Section 11.24.4) attribute of the capture scene the media capture belongs to. Indeed, all the spatially definable media captures referring to the same capture scene share the same coordinate system and express their spatial information according to the same scale. 11.5.1. The element is used to represent the position and optionally the line of capture of a capture device. MUST be included in spatially definable audio captures, while it is optional for spatially definable video captures. Presta & Romano Expires April 21, 2016 [Page 21] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 The XML Schema definition of the element type is the following: The point type contains three spatial coordinates (x,y,z) representing a point in the space associated with a certain capture scene. The element includes a mandatory element and an optional element, both of the type "pointType". specifies the three coordinates identifying the position of the capture device. is another pointType element representing the "point on line of capture", that gives the pointing direction of the capture device. The coordinates of the point on line of capture MUST NOT be identical to the capture point coordinates. For a spatially definable video capture, if the point on line of capture is provided, it MUST belong to the region between the point of capture and the capture area. For a spatially definable audio capture, if the point on line of capture is not provided, the sensitivity pattern should be considered omnidirectional. 11.5.2. is an optional element that can be contained within the spatial information associated with a media capture. It represents Presta & Romano Expires April 21, 2016 [Page 22] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 the spatial area captured by the media capture. MUST be included in the spatial information of spatially definable video captures, while it MUST NOT be associated with audio captures. The XML representation of that area is provided through a set of four point-type elements, , , , and that MUST be co-planar. The four coplanar points are identified from the perspective of the capture device. The XML schema definition is the following: 11.6. When media captures are non spatially definable, they MUST be marked with the boolean element set to "true" and no MUST be provided. Indeed, and are mutually exclusive tags, according to the section within the XML Schema definition of the media capture type. 11.7. A media capture can be (i) an individual media capture or (ii) a multiple content capture (MCC). A multiple content capture is made by different captures that can be arranged spatially (by a composition operation), or temporally (by a switching operation), or that can result from the orchestration of both the techniques. If a media capture is an MCC, then it MAY show in its XML data model representation the element. It is composed by a list of media capture identifiers ("captureIDREF") and capture scene view identifiers ("sceneViewIDREF"), where the last ones are used as shortcuts to refer to multiple capture identifiers. The referenced captures are used to create the MCC according to a certain strategy. If the element does not appear in a MCC, or it has no child elements, then the MCC is assumed to be made of multiple sources but no information regarding those sources is provided. Presta & Romano Expires April 21, 2016 [Page 23] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 11.8. is an optional element for multiple content captures that contains a numeric identifier. Multiple content captures marked with the same identifier in the contain at all times captures coming from the same sources. It is the Media Provider that determines what the source for the captures is. In this way, the Media Provider can choose how to group together single captures for the purpose of keeping them synchronized according to the element. 11.9. is an optional boolean element for multiple content captures. It indicates whether or not the Provider allows the Consumer to choose a specific subset of the captures referenced by the MCC. If this attribute is true, and the MCC references other captures, then the Consumer MAY specify in a CONFIGURE message a specific subset of those captures to be included in the MCC, and the Provider MUST then include only that subset. If this attribute is false, or the MCC does not reference other captures, then the Consumer MUST NOT select a subset. If is not shown in the XML description of the MCC, its value is to be considered "false". 11.10. is an optional element that can be used only for multiple content captures. It indicates the criteria applied to build the multiple content capture using the media captures referenced in . The value is in the form of a token that indicates the policy and an index representing an instance of the policy, separated by a ":" (e.g., SoundLevel:2, RoundRobin:0, Presta & Romano Expires April 21, 2016 [Page 24] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 etc.). The XML schema defining the type of the element is the following: At the time of writing, only two switching policies are defined in [I-D.ietf-clue-framework]: SoundLevel: the content of the MCC is determined by a sound level detection algorithm. The loudest (active) speaker (or a previous speaker, depending on the index value) is contained in the MCC. Index 0 represents the most current instance of the policy, i.e., the currently active speaker, 1 represents the previous instance, i.e., the previous active speaker, and so on. RoundRobin: the content of the MCC is determined by a time based algorithm. Other values for the element can be used. In this case, it is assumed that implementations agree on the meaning of those other values and/or those new switching policies are defined in later documents. 11.11. is an optional element that can be used only for multiple content captures (MCC). It provides information about the number of media captures that can be represented in the multiple content capture at a time. If is not provided, all the media captures listed in the element can appear at a time in the capture encoding. The type definition is provided below. Presta & Romano Expires April 21, 2016 [Page 25] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 When the "exactNumber" attribute is set to "true", it means the element carries the exact number of the media captures appearing at a time. Otherwise, the number of the represented media captures MUST be considered "<=" the value. For instance, an audio MCC having the value set to 1 means that a media stream from the MCC will only contain audio from a single one of its constituent captures at a time. On the other hand, if the value is set to 4 and the exactNumber attribute is set to "true", it would mean that the media stream received from the MCC will always contain a mix of audio from exactly four of its constituent captures. 11.12. is a boolean element that MUST be used for single- content captures. Its value is fixed and set to "true". Such element indicates the capture that is being described is not a multiple content capture. Indeed, and the aforementioned tags related to MCC attributes (from Section 11.7 to Section 11.11) are mutually exclusive, according to the section within the XML Schema definition of the media capture type. 11.13. is used to provide human-readable textual information. This element is included in the XML definition of media captures, capture scenes and capture scene views to the aim of providing human- readable description of, respectively, media captures, capture scenes and capture scene views. According to the data model definition of a media capture (Section 11)), zero or more elements can be used, each providing information in a different language. The element definition is the following: Presta & Romano Expires April 21, 2016 [Page 26] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 As can be seen, is a string element with an attribute ("lang") indicating the language used in the textual description. 11.14. is an optional unsigned integer field indicating the importance of a media capture according to the Media Provider's perspective. It can be used on the receiver's side to automatically identify the most relevant contribution from the Media Provider. The higher the importance, the lower the contained value. If no priority is assigned, no assumptions regarding relative importance of the media capture can be assumed. 11.15. is an optional element containing the language used in the capture. Zero or more elements can appear in the XML description of a media capture. 11.16. is an optional element indicating whether or not the capture device originating the capture may move during the telepresence session. That optional element can assume one of the three following values: static SHOULD NOT change for the duration of the CLUE session, across multiple ADVERTISEMENT messages. dynamic MAY change in each new ADVERTISEMENT message. Can be assumed to remain unchanged until there is a new ADVERTISEMENT message. highly-dinamic MAY change dynamically, even between consecutive ADVERTISEMENT messages. The spatial information provided in an ADVERTISEMENT message is simply a snapshot of the current values at the time when the message is sent. 11.17. The optional element contains the value of the captureID attribute (Section 11.1) of the media capture to which the considered media capture refers. The media capture marked with a element can be for example the translation of the referred media capture in a different language. Presta & Romano Expires April 21, 2016 [Page 27] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 11.18. The element is an optional tag describing what is represented in the spatial area covered by a media capture. The current possible values are: "table", "lectern", "individual", and "audience", as listed in the enumerative view type in the following. 11.19. The element is an optional tag used for media captures conveying information about presentations within the telepresence session. The current possible values are "slides" and "images", as listed in the enumerative presentation type in the following. 11.19.1. The element is a boolean element indicating that there is text embedded in the media capture (e.g., in a video capture). The language used in such embedded textual description is reported in "lang" attribute. The XML Schema definition of the element is: Presta & Romano Expires April 21, 2016 [Page 28] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 11.19.2. This optional element is used to indicate which telepresence session participants are represented within the media captures. For each participant, a element is provided. 11.19.2.1. contains the identifier of the represented person, i.e., the value of the related personID attribute (Section 11.29.1.1). Metadata about the represented participant can be retrieved by accessing the list (Section 11.29). 11.20. Audio captures Audio captures inherit all the features of a generic media capture and present further audio-specific characteristics. The XML Schema definition of the audio capture type is reported below: Presta & Romano Expires April 21, 2016 [Page 29] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 An example of audio-specific information that can be included is represented by the element. (Section 11.20.1). 11.20.1. The element is an optional field describing the characteristics of the nominal sensitivity pattern of the microphone capturing the audio signal. The XML Schema definition is provided below: 11.21. Video captures Video captures, similarly to audio captures, extend the information of a generic media capture with video-specific features. The XML Schema representation of the video capture type is provided in the following: Presta & Romano Expires April 21, 2016 [Page 30] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 11.22. Text captures Also text captures can be described by extending the generic media capture information, similarly to audio captures and video captures. The XML Schema representation of the text capture type is currently lacking text-specific information, as it can be seen by looking at the definition below: Text captures SHOULD be marked as non spatially definable (i.e., they should present in their XML description the (Section 11.6) element set to "true"). 11.23. Other capture types Other media capture types can be described by using the CLUE data model. They can be represented by exploiting the "otherCaptureType" type. This media capture type is conceived to be filled in with elements defined within extensions of the current schema, i.e., with elements defined in other XML schemas (see Section 14 for an example). The otherCaptureType inherits all the features envisioned for the abstract mediaCaptureType. The XML Schema representation of the otherCaptureType is the following: Presta & Romano Expires April 21, 2016 [Page 31] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 When defining new media capture types that are going to be described by means of the element, spatial properties of such new media capture types SHOULD be defined (e.g., whether or not they are spatially definable, whether or not they should be associated with an area of capture, etc.). 11.24. A Media Provider organizes the available captures in capture scenes in order to help the receiver both in the rendering and in the selection of the group of captures. Capture scenes are made of media captures and capture scene views, that are sets of media captures of the same media type. Each capture scene view is an alternative to represent completely a capture scene for a fixed media type. The XML Schema representation of a element is the following: Presta & Romano Expires April 21, 2016 [Page 32] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 Each capture scene is identified by a "sceneID" attribute. The element can contain zero or more textual elements, defined as in Section 11.13. Besides , there is the optional element (Section 11.24.1), which contains structured information about the scene in the vcard format, and the optional element (Section 11.24.2), which is the list of the capture scene views. When no is provided, the capture scene is assumed to be made of all the media captures which contain the value of its sceneID attribute in their mandatory captureSceneIDREF attribute. 11.24.1. The element contains optional information about the capture scene according to the vcard format. 11.24.2. The element is a mandatory field of a capture scene containing the list of scene views. Each scene view is represented by a element (Section 11.25). 11.24.3. sceneID attribute The sceneID attribute is a mandatory attribute containing the identifier of the capture scene. 11.24.4. scale attribute The scale attribute is a mandatory attribute that specifies the scale of the coordinates provided in the spatial information of the media capture belonging to the considered capture scene. The scale attribute can assume three different values: Presta & Romano Expires April 21, 2016 [Page 33] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 "mm" - the scale is in millimeters. Systems which know their physical dimensions (for example professionally installed telepresence room systems) should always provide such real-world measurements. "unknown" - the scale is the same for every media capture in the capture scene but the unity of measure is undefined. Systems which are not aware of specific physical dimensions yet still know relative distances should select "unknown" in the scale attribute of the capture scene to be described. "noscale" - there is no common physical scale among the media captures of the capture scene. That means the scale could be different for each media capture. 11.25. A element represents a capture scene view, which contains a set of media captures of the same media type describing a capture scene. A element is characterized as follows. Presta & Romano Expires April 21, 2016 [Page 34] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 One or more optional elements provide human-readable information about what the scene view contains. is defined as already seen in Section 11.13. The remaining child elements are described in the following subsections. 11.25.1. The is the list of the identifiers of the media captures included in the scene view. It is an element of the captureIDListType type, which is defined as a sequence of , each containing the identifier of a media capture listed within the element: 11.25.2. sceneViewID attribute The sceneViewID attribute is a mandatory attribute containing the identifier of the capture scene view represented by the element. 11.26. The element represents an encoding group, which is made by a set of one or more individual encodings and some parameters that apply to the group as a whole. Encoding groups contain references to individual encodings that can be applied to media captures. The definition of the element is the following: Presta & Romano Expires April 21, 2016 [Page 35] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 In the following, the contained elements are further described. 11.26.1. is an optional field containing the maximum bitrate expressed in bits per second that can be shared by the individual encodings included in the encoding group. 11.26.2. is the list of the individual encodings grouped together in the encoding group. Each individual encoding is represented through its identifier contained within an element. 11.26.3. encodingGroupID attribute The encodingGroupID attribute contains the identifier of the encoding group. 11.27. represents a simultaneous transmission set, i.e., a list of captures of the same media type that can be transmitted at the same time by a Media Provider. There are different simultaneous Presta & Romano Expires April 21, 2016 [Page 36] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 transmission sets for each media type. Besides the identifiers of the captures ( elements), also the identifiers of capture scene views and of capture scene can be exploited as shortcuts ( and elements). As an example, let's consider the situation where there are two capture scene views (S1 and S7). S1 contains captures AC11, AC12, AC13. S7 contains captures AC71, AC72. Provided that AC11, AC12, AC13, AC71, AC72 can be simultaneously sent to the media consumer, instead of having 5 elements listed in the simultaneous set (i.e., one for AC11, one for AC12, and so on), there can be just two elements (one for S1 and one for S7). 11.27.1. setID attribute The "setID" attribute is a mandatory field containing the identifier of the simultaneous set. 11.27.2. mediaType attribute The "mediaType" attribute is an optional attribute containing the media type of the captures referenced by the simultaneous set. When only capture scene identifiers are listed within a simultaneous set, the media type attribute MUST appear in the XML description in order to determine which media captures can be simultaneously sent together. Presta & Romano Expires April 21, 2016 [Page 37] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 11.27.3. contains the identifier of the media capture that belongs to the simultanous set. 11.27.4. contains the identifier of the scene view containing a group of captures that are able to be sent simultaneously with the other captures of the simultaneous set. 11.27.5. contains the identifier of the capture scene where all the included captures of a certain media type are able to be sent together with the other captures of the simultaneous set. 11.28. is a set of captures of the same media type representing a summary of the complete Media Provider's offer. The content of a global view is expressed by leveraging only scene view identifiers, put within elements. Each global view is identified by a unique identifier within the "globalViewID" attribute. 11.29. Information about the participants that are represented in the media captures is conveyed via the element. As it can be seen from the XML Schema depicted below, for each participant, a element is provided. Presta & Romano Expires April 21, 2016 [Page 38] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 11.29.1. includes all the metadata related to a person represented within one or more media captures. Such element provides the vcard of the subject (via the element, see Section 11.29.1.2) and his conference role(s) (via one or more elements, see Section 11.29.1.3). Furthermore, it has a mandatory "personID" attribute (Section 11.29.1.1). 11.29.1.1. personID attribute The "personID" attribute carries the identifier of a represented person. Such an identifier can be used to refer to the participant, as in the element in the media captures representation (Section 11.19.2). 11.29.1.2. The element is the XML representation of all the fields composing a vcard as specified in the Xcard RFC [RFC6351]. The vcardType is imported by the Xcard XML Schema provided by Presta & Romano Expires April 21, 2016 [Page 39] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 [I-D.ietf-ecrit-additional-data]. As such schema specifies, the element within is mandatory. 11.29.1.3. The value of the element determines the role of the represented participant within the telepresence session organization. It can be one of the following terms, that are defined in the framework document: "presenter", "timekeeper", "attendee", "minute taker", "translator", "chairman", "vice-chairman". A participant can play more than one conference role. In that case, more than one element will appear in his description. 12. A capture encoding is given from the association of a media capture with an individual encoding, to form a capture stream as defined in [I-D.ietf-clue-framework]. Capture encodings are used within CONFIGURE messages from a Media Consumer to a Media Provider for representing the streams desired by the Media Consumer. For each desired stream, the Media Consumer needs to be allowed to specify: (i) the capture identifier of the desired capture that has been advertised by the Media Provider; (ii) the encoding identifier of the encoding to use, among those advertised by the Media Provider; (iii) optionally, in case of multi-content captures, the list of the capture identifiers of the desired captures. All the mentioned identifiers are intended to be included in the ADVERTISEMENT message that the CONFIGURE message refers to. The XML model of Presta & Romano Expires April 21, 2016 [Page 40] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 is provided in the following. 12.1. is the mandatory element containing the identifier of the media capture that has been encoded to form the capture encoding. 12.2. is the mandatory element containing the identifier of the applied individual encoding. 12.3. is an optional element to be used in case of configuration of MCC. It contains the list of capture identifiers and capture scene view identifiers the Media Consumer wants within the MCC. That element is structured as the element used to describe the content of an MCC. The total number of media captures listed in the must be lower than or equal to the value carried within the attribute of the MCC. 13. The element includes all the information needed to represent the Media Provider's description of its telepresence capabilities according to the CLUE framework. Indeed, it is made by: the list of the available media captures ( (Section 5)) Presta & Romano Expires April 21, 2016 [Page 41] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 the list of encoding groups ( (Section 6)) the list of capture scenes ( (Section 7)) the list of simultaneous transmission sets ( (Section 8)) the list of global views sets ( (Section 9)) meta data about the participants represented in the telepresence session ( (Section 11.29)). It has been conceived only for data model testing purposes and, though it resembles the body of an ADVERTISEMENT message, it is not actually used in the CLUE protocol message definitions. The telepresence capabilities descriptions compliant to this data model specification that can be found in Section 17 and Section 18 are provided by using the element. 14. XML Schema extensibility The telepresence data model defined in this document is meant to be extensible. Extensions are accomplished by defining elements or attributes qualified by namespaces other than "urn:ietf:params:xml:ns:clue-info" and "urn:ietf:params:xml:ns:vcard-4.0" for use wherever the schema allows such extensions (i.e., where the XML Schema definition specifies "anyAttribute" or "anyElement"). Elements or attributes from unknown Presta & Romano Expires April 21, 2016 [Page 42] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 namespaces MUST be ignored. 14.1. Example of extension When extending the CLUE data model, a new schema with a new namespace associated with it needs to be specified. In the following, an example of extension is provided. The extension defines a new audio capture attribute ("newAudioFeature") and an attribute for characterizing the captures belonging to an "otherCaptureType" defined by the user. An XML document compliant with the extension is also included. The XML file results validated against the current CLUE data model schema. Presta & Romano Expires April 21, 2016 [Page 43] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 CS1 true true EG1 newAudioFeatureValue CS1 true EG1 OtherValue 300000 ENC4 ENC5 15. Security considerations This document defines an XML Schema data model for telepresence scenarios. The modeled information is identified in the CLUE framework as necessary in order to enable a full-optional media stream negotiation and rendering. Indeed, the XML elements herein Presta & Romano Expires April 21, 2016 [Page 44] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 defined are used within CLUE protocol messages to describe both the media streams representing the Media Provider's telepresence offer and the desired selection requested by the Media Consumer. Security concerns described in [I-D.ietf-clue-framework], Section 15, apply to this document. Data model information carried within CLUE messages SHOULD be accessed only by authenticated endpoints. Indeed, some information published by the Media Provider might reveal sensitive data about who and what is represented in the transmitted streams. The vCard included in the elements (Section 11.29.1) mandatorily contains the identity of the represented person. Optionally vCards can also carry the person's contact addresses, together with his/her photo and other personal data. Similar privacy-critical information can be conveyed by means of elements (Section 11.24.1) describing the capture scenes. The elements (Section 11.13) also can specify details about the content of media captures , capture scenes and scene views that should be protected. Integrity attacks to the data model information encapsulated in CLUE messages can invalidate the success of the telepresence session's setup by misleading the Media Consumer's and Media Provider's interpretation of the offered and desired media streams. The assurance of the authenticated access and of the integrity of the data model information is up to the involved transport mechanisms, namely the CLUE protocol [I-D.ietf-clue-protocol] and the CLUE data channel [I-D.ietf-clue-datachannel]. 16. IANA considerations This document registers a new XML namespace, a new XML schema and the MIME type for the schema. 16.1. XML namespace registration URI: urn:ietf:params:xml:ns:clue-info Registrant Contact: IETF CLUE Working Group , Roberta Presta XML: Presta & Romano Expires April 21, 2016 [Page 45] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 BEGIN CLUE Data Model Namespace

Namespace for CLUE Data Model

urn:ietf:params:xml:ns:clue-info

See RFC XXXX.

END 16.2. XML Schema registration This section registers an XML schema per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:schema:clue-info Registrant Contact: CLUE working group (clue@ietf.org), Roberta Presta (roberta.presta@unina.it). Schema: The XML for this schema can be found as the entirety of Section 4 of this document. 16.3. MIME Media Type Registration for 'application/clue_info+xml' This section registers the "application/clue_info+xml" MIME type. To: ietf-types@iana.org Subject: Registration of MIME media type application/clue+xml MIME media type name: application MIME subtype name: clue_info+xml Presta & Romano Expires April 21, 2016 [Page 46] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 Required parameters: (none) Optional parameters: charset Same as the charset parameter of "application/xml" as specified in [RFC7303], Section 3.2. Encoding considerations: Same as the encoding considerations of "application/xml" as specified in [RFC7303], Section 3.2. Security considerations: This content type is designed to carry data related to telepresence information. Some of the data could be considered private. This media type does not provide any protection and thus other mechanisms such as those described in Section 15 are required to protect the data. This media type does not contain executable content. Interoperability considerations: None. Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number for this specification.]] Applications that use this media type: None. Additional Information: Magic Number(s): (none), File extension(s): .clue, Macintosh File Type Code(s): TEXT. Person & email address to contact for further information: Roberta Presta (roberta.presta@unina.it). Intended usage: LIMITED USE Author/Change controller: The IETF Other information: This media type is a specialization of application/xml [RFC7303], and many of the considerations described there also apply to application/clue_info+xml. 17. Sample XML file The following XML document represents a schema compliant example of a CLUE telepresence scenario. Taking inspiration from the examples described in the framework draft ([I-D.ietf-clue-framework]), it is provided the XML representation of an endpoint-style Media Provider's offer. There are three cameras, where the central one is also capable of capturing a zoomed-out view of the overall telepresence room. Presta & Romano Expires April 21, 2016 [Page 47] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 Besides the three video captures coming from the cameras, the Media Provider makes available a further multi-content capture of the loudest segment of the room, obtained by switching the video source across the three cameras. For the sake of simplicity, only one audio capture is advertised for the audio of the whole room. The three cameras are placed in front of three participants (Alice, Bob and Ciccio), whose vcard and conference role details are also provided. Media captures are arranged into four capture scene views: 1. (VC0, VC1, VC2) - left, center and right camera video captures 2. (VC3) - video capture associated with loudest room segment 3. (VC4) - video capture zoomed out view of all people in the room 4. (AC0) - main audio There are two encoding groups: (i) EG0, for video encodings, and (ii) EG1, for audio encodings. As to the simultaneous sets, only VC1 and VC4 cannot be transmitted simultaneously since they are captured by the same device, i.e., the central camera (VC4 is a zoomed-out view while VC1 is a focused view of the front participant). The simultaneous sets would then be the following: SS1 made by VC3 and all the captures in the first capture scene view (VC0,VC1,VC2); SS2 made by VC3, VC0, VC2, VC4 CS1 EG1 Presta & Romano Expires April 21, 2016 [Page 48] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 0.5 1.0 0.5 0.5 0.0 0.5 true main audio from the room 1 it static room alice bob ciccio CS1 EG0 0.5 1.0 0.5 0.5 0.0 0.5 true left camera video capture 1 it static individual Presta & Romano Expires April 21, 2016 [Page 49] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 ciccio CS1 EG0 0.5 1.0 0.5 0.5 0.0 0.5 true central camera video capture 1 it static individual alice CS1 EG0 0.5 1.0 0.5 0.5 0.0 0.5 Presta & Romano Expires April 21, 2016 [Page 50] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 true right camera video capture 1 it static individual bob CS1 EG0 true Soundlevel:0 loudest room segment 1 it static individual CS1 EG0 0.5 1.0 0.5 0.5 0.0 0.5 true zoomed out view of all people in the room 1 it static room Presta & Romano Expires April 21, 2016 [Page 51] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 alice bob ciccio 600000 ENC1 ENC2 ENC3 300000 ENC4 ENC5 VC0 VC1 VC2 VC3 VC4 VC4 Presta & Romano Expires April 21, 2016 [Page 52] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 VC3 SE1 VC0 VC2 VC4 VC3 Bob minute taker Alice presenter Ciccio chairman timekeeper Presta & Romano Expires April 21, 2016 [Page 53] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 18. MCC example Enhancing the scenario presented in the previous example, the Media Provider is able to advertise a composed capture VC7 made by a big picture representing the current speaker (VC3) and two picture-in- picture boxes representing the previous speakers (the previous one -VC5- and the oldest one -VC6). The provider does not want to instantiate and send VC5 and VC6, so it does not associate any encoding group with them. Their XML representations are provided for enabling the description of VC7. A possible description for that scenario could be the following: CS1 EG1 0.5 1.0 0.5 0.5 0.0 0.5 true main audio from the room 1 it static room alice bob ciccio Presta & Romano Expires April 21, 2016 [Page 54] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 CS1 EG0 0.5 1.0 0.5 0.5 0.0 0.5 true left camera video capture 1 it static individual ciccio CS1 EG0 0.5 1.0 0.5 0.5 0.0 0.5 true Presta & Romano Expires April 21, 2016 [Page 55] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 central camera video capture 1 it static individual alice CS1 EG0 0.5 1.0 0.5 0.5 0.0 0.5 true right camera video capture 1 it static individual bob CS1 EG0 true SE1 Soundlevel:0 loudest room segment 1 Presta & Romano Expires April 21, 2016 [Page 56] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 it static individual CS1 EG0 0.5 1.0 0.5 0.5 0.0 0.5 true zoomed out view of all people in the room 1 it static room alice bob ciccio CS1 true SE1 Soundlevel:1 penultimate loudest room segment 1 it static Presta & Romano Expires April 21, 2016 [Page 57] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 individual CS1 true SE1 Soundlevel:2 last but two loudest room segment 1 it static individual CS1 true VC3 VC5 VC6 big picture of the current speaker + pips about previous speakers 1 it static individual 600000 ENC1 ENC2 ENC3 300000 ENC4 ENC5 Presta & Romano Expires April 21, 2016 [Page 58] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 participants' individual videos VC0 VC1 VC2 loudest segment of the room VC3 loudest segment of the room + pips VC7 room audio AC0 room video VC4 VC7 SE1 Presta & Romano Expires April 21, 2016 [Page 59] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 VC0 VC2 VC4 VC7 Bob minute taker Alice presenter Ciccio chairman timekeeper 19. Diff with draft-ietf-clue-data-model-schema-10 version Minor modifications have been applied to address nits at page https:/ /www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/ draft-ietf-clue-data-model-schema-10.txt. Presta & Romano Expires April 21, 2016 [Page 60] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 20. Diff with draft-ietf-clue-data-model-schema-09 version o We have introduced a element containing a mandatory and an optional in the definition of as per Paul's review o A new type definition for switching policies (resembled by element) has been provided in order to have acceptable values in the form of "token:index". o Minor modifications suggested in WGLC reviews have been applied. 21. Diff with draft-ietf-clue-data-model-schema-08 version o Typos correction 22. Diff with draft-ietf-clue-data-model-schema-07 version o IANA Considerations: text added o maxCaptureEncodings removed o personTypeType values aligned with CLUE framework o allowSubsetChoice added for multiple content captures o embeddedText moved from videoCaptureType definition to mediaCaptureType definition o typos removed from section Terminology 23. Diff with draft-ietf-clue-data-model-schema-06 version o Capture Scene Entry/Entries renamed as Capture Scene View/Views in the text, / renamed as / in the XML schema. o Global Scene Entry/Entries renamed as Global View/Views in the text, / renamed as / o Security section added. o Extensibility: a new type is introduced to describe other types of media capture (otherCaptureType), text and example added. o Spatial information section updated: capture point optional, text now is coherent with the framework one. Presta & Romano Expires April 21, 2016 [Page 61] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 o Audio capture description: added, removed, disallowed. o Simultaneous set definition: added to refer to capture scene identifiers as shortcuts and an optional mediaType attribute which is mandatory to use when only capture scene identifiers are listed. o Encoding groups: removed the constraint of the same media type. o Updated text about media captures without (optional in the XML schema). o "mediaType" attribute removed from homogeneous groups of capture (scene views and globlal views) o "mediaType" attribute removed from the global view textual description. o "millimeters" scale value changed in "mm" 24. Diff with draft-ietf-clue-data-model-schema-04 version globalCaptureEntries/Entry renamed as globalSceneEntries/Entry; sceneInformation added; Only capture scene entry identifiers listed within global scene entries (media capture identifiers removed); renamed as in the >clueInfo< template renamed as to synch with the framework terminology renamed as to synch with the framework terminology renamed as in the media capture type definition to remove ambiguity Examples have been updated with the new definitions of and of . Presta & Romano Expires April 21, 2016 [Page 62] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 25. Diff with draft-ietf-clue-data-model-schema-03 version encodings section has been removed global capture entries have been introduced capture scene entry identifiers are used as shortcuts in listing the content of MCC (similarly to simultaneous set and global capture entries) Examples have been updated. A new example with global capture entries has been added. has been made optional. has been renamed into Obsolete comments have been removed. participants information has been added. 26. Diff with draft-ietf-clue-data-model-schema-02 version captureParameters and encodingParameters have been removed from the captureEncodingType data model example has been updated and validated according to the new schema. Further description of the represented scenario has been provided. A multiple content capture example has been added. Obsolete comments and references have been removed. 27. Acknowledgments The authors thank all the CLUErs for their precious feedbacks and support. 28. Informative References [I-D.ietf-clue-datachannel] Holmberg, C., "CLUE Protocol data channel", draft-ietf-clue-datachannel-10 (work in progress), September 2015. [I-D.ietf-clue-framework] Duckworth, M., Pepperell, A., and S. Wenger, "Framework for Presta & Romano Expires April 21, 2016 [Page 63] Internet-Draft draft-ietf-clue-data-model-schema-11 October 2015 Telepresence Multi-Streams", draft-ietf-clue-framework-23 (work in progress), September 2015. [I-D.ietf-clue-protocol] Presta, R. and S. Romano, "CLUE protocol", draft-ietf-clue-protocol-06 (work in progress), October 2015. [I-D.ietf-ecrit-additional-data] Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and J. Winterbottom, "Additional Data Related to an Emergency Call", draft-ietf-ecrit-additional-data-37 (work in progress), October 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, < http://www.rfc-editor.org/info/ rfc2119>. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, . [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, DOI 10.17487/RFC5117, January 2008, . [RFC6351] Perreault, S., "xCard: vCard XML Representation", RFC 6351, DOI 10.17487/RFC6351, August 2011, . [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, DOI 10.17487/RFC7303, July 2014, . Authors' Addresses Roberta Presta University of Napoli Via Claudio 21 Napoli 80125 Italy EMail: roberta.presta@unina.it Simon Pietro Romano University of Napoli Via Claudio 21 Napoli 80125 Italy EMail: spromano@unina.it Presta & Romano Expires April 21, 2016 [Page 65]