CLUE A. Romanow Internet-Draft Cisco Systems Intended status: Standards Track A. Pepperell Expires: December 8, 2012 Silverflare June 6, 2012 Data model for the CLUE Framework draft-romanow-clue-data-model-01 Abstract This draft is for discussion in the CLUE working group. It proposes a data model for the CLUE Framework. 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 December 8, 2012. Copyright Notice Copyright (c) 2012 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. Romanow & Pepperell Expires December 8, 2012 [Page 1]
Internet-Draft Data Model for CLUE June 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Data model format . . . . . . . . . . . . . . . . . . . . 4 3.2. Data model namespace . . . . . . . . . . . . . . . . . . . 4 3.3. Data Model Structure . . . . . . . . . . . . . . . . . . . 4 4. Data Model Definition . . . . . . . . . . . . . . . . . . . . 4 4.1. <CLUE-info> . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. <capture-description> . . . . . . . . . . . . . . . . . . 6 4.3. <capture-id> . . . . . . . . . . . . . . . . . . . . . . . 6 4.4. <media-type> . . . . . . . . . . . . . . . . . . . . . . . 6 4.5. <content-type> . . . . . . . . . . . . . . . . . . . . . . 6 4.6. <DERIVED> . . . . . . . . . . . . . . . . . . . . . . . . 6 4.7. <switched> . . . . . . . . . . . . . . . . . . . . . . . . 6 4.8. <spatial-description> . . . . . . . . . . . . . . . . . . 7 4.8.1. <point-of-capture> . . . . . . . . . . . . . . . . . . 7 4.8.2. <capture-area> . . . . . . . . . . . . . . . . . . . . 7 4.8.3. <NATIVE-ASPECT_RATIO> . . . . . . . . . . . . . . . . 7 4.9. <audio-channel-format> . . . . . . . . . . . . . . . . . . 7 4.10. <encoding-group-id> . . . . . . . . . . . . . . . . . . . 7 4.11. <future-media-capture-attribute> . . . . . . . . . . . . . 7 4.12. <capture-scene> . . . . . . . . . . . . . . . . . . . . . 7 4.12.1. <capture-scene-text> . . . . . . . . . . . . . . . . . 8 4.12.2. <capture-scene-language> . . . . . . . . . . . . . . . 8 4.12.3. <capture-scene-spatial-description> . . . . . . . . . 8 4.12.4. <future-capture-scene-attribute> . . . . . . . . . . . 8 4.13. <simultaneous transmission-set> . . . . . . . . . . . . . 8 4.14. <stream-description> . . . . . . . . . . . . . . . . . . . 9 4.14.1. <encoding> . . . . . . . . . . . . . . . . . . . . . . 9 4.14.2. <encoding-group> . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Romanow & Pepperell Expires December 8, 2012 [Page 2]
Internet-Draft Data Model for CLUE June 2012 1. Introduction This document proposes a data model for the CLUE Framework [I-D.ietf- clue-framework]. The previous suggestion for a data model described the 2 CLUE messages, provider advertisement and consumer choice message. The data model proposed here differs in that it describes the basic information, or definitions that are needed. Messages can then derived from the data model, similarly to what was described in the earlier data model. The provider advertisement and the consumer choice messages can use or not use any of the data elements defined in the data model, subject only to whether or not the element is deemed mandatory. The model here follows the example of the xcon data model RFC 6501 [RFC6501]. Initially the data model may seem to describe only provider advertisements. But this is not the case. The consumer choice messages can also be constructed from these elements. Many of the data elements are similar for both messages, but there are also elements defined which are used only in one or the other of the messages. One of the challenges here is that in addition to proposing a structure for the data model, we would like to also propose some additions or changes to what is in the current framework document. The problem is that any changes from what is in the current framework can detract attention from the basic information model which is the primary focus of this draft initially. We have noted where there are changes from the framework by putting the text in all capital text. This is a rough draft, its goal is to propose a basic structure and stimulate discussion. 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 RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. Romanow & Pepperell Expires December 8, 2012 [Page 3]
Internet-Draft Data Model for CLUE June 2012 3. Overview TEXT 3.1. Data model format A CLUE object document is an XML [W3C.REC-xml-20081126] document. CLUE object documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. 3.2. Data model namespace This specification defines a new namespace specification for identifying the elements defined in the data model. This namespace is as follows: urn:ietf:params:xml:ns:clue-info 3.3. Data Model Structure The information in this data model is structured in the following manner. All the information communicated between consumers and providers in a CLUE session is contained in a <CLUE-info> element. The definitions follow directly from the Framework document. The <CLUE-info> element contains the following child elements: o The <capture-description> element describes the captures. It includes all the elements that have been discussed in the framework document as properties of captures document and it can be extended by adding additional elements describing a capture. o The <capture-scene> element is the data structure that describes the captures that the provider is capable of sending in a way that is helpfule to the consumer to decide what captures to request. o The <simultaneous-transmission-set> element is a data structure that describes the physical simultaneity constraints, as discussed in the framework. o The<stream-description> element describes the encoding characteristics of the streams. 4. Data Model Definition The following non-normative diagram shows the structure of CLUE elements. The symbol "!" preceding an element indicates that the element is REQUIRED in the data model. Romanow & Pepperell Expires December 8, 2012 [Page 4]
Internet-Draft Data Model for CLUE June 2012 !<CLUE info> | |--<capture-description> | |--<capture-id> | |--<media-type> | |--<content-type> | |--<DERIVED> | |--<switched> | |--<spatial-description> | | |--<point-of-capture> | | |--<capture-area> | | |--<NATIVE-ASPECT-RATIO> | |--<audio-channel-format> | |--<encoding-group-ID> | |--<future-media-capture-attribute> |--<capture-scene> | |--<entry> | | |--<capture-id> | | |--<switch-policy | |--<capture-scene-text> | |--<capture-scene-language> | |--<capture-scene-spatial-description> | | |--<capture-scene-area> | | |--<capture-scene-scale> | |--<future-capture-scene-attribute> |--<simultaneous-transmission-set> | |--<entry> | | |--<capture-id> |--<stream-description> | |--<encoding> | | |--<encoding-id> | | |--<multiplex-id> | | |--<AUDIO-RENDERING-ID> | | |--<max-audio-bandwidth> | | |--<max-video-bandwidth> | | |--<max-H264-Mbps> | | |--<max-width> | | |--<max-height> | | |--<max-frame-rate> | | |--<future-encoding-attribute> | |--<encoding-group> | | |--<encoding-group-id> | | |--<entry> | | <video encoding> | | |--><entry> | | |<audio encoding> | | |--<max-group-bandwidth> | | |--<max-group-H264-<Mbps> Romanow & Pepperell Expires December 8, 2012 [Page 5]
Internet-Draft Data Model for CLUE June 2012 | | |--<future-encoding-group-attribute> Data Model Definition The following sections describe these elements in more detail. 4.1. <CLUE-info> 4.2. <capture-description> The capture-description describes all the aspects of a capture, as discussed in the framework document. 4.3. <capture-id> This element is a unique numeric value assigned to each capture by the provider. It is used by the consumer in choosing captures and streams. 4.4. <media-type> This element indicates support by the consumer for a single capture media type, for instance "audio" or "video". 4.5. <content-type> This per-capture attribute element indicates whether the media capture includes "main media", typically motion video of a real scene, or whether it includes "slides media", typically a computer- generated video stream rather than real people. This is following the content attribute RFC [ref]. 4.6. <DERIVED> Instead of the boolean composed, we are suggesting an attribute that indicates whether media capture has been changed from its original form. It can take different values. As of now, the only vlaue defined is composed. Composed means a video image it is formed of other, more primary, captures mixed together. For audio it refers to mixed audio.[this needs to follow whatever the WG decides as to whether there is an audio composed, etc.] 4.7. <switched> Instead of a boolean, we propose this attribute indicates the algorithm or method by which content is chosen form media sources. Romanow & Pepperell Expires December 8, 2012 [Page 6]
Internet-Draft Data Model for CLUE June 2012 The current value is loudest speaker. [this depends entirely on what the WG decides] 4.8. <spatial-description> Spatial-description is a general element with sub-elements that describe spatial relationships. As of now, the framework defines point-of-capture and capture-area. We propose a third one here- NATIVE-ASPECT-RATIO. 4.8.1. <point-of-capture> Use framework text. 4.8.2. <capture-area> Use framework text. 4.8.3. <NATIVE-ASPECT_RATIO> If a capture has a native aspect ratio (for instance, it corresponds to a camera that generates 4:3 video) then it can be supplied here. This can help rendering. 4.9. <audio-channel-format> Use framework text. 4.10. <encoding-group-id> This element is a unique numeric value assigned to each encoding group by the provider. It is included in a capture element because it links the capture to the group of encodings possible to use for the capture. 4.11. <future-media-capture-attribute> This is a placeholder for media capture attributes that have yet to be defined. 4.12. <capture-scene> A capture-scene is a description of the captures that the provider is capable of sending. It includes entries which are rows of audio or video captures. Information concerning the relationship between captures is communicated by the capture-scene, that is, an entry in the capture- Romanow & Pepperell Expires December 8, 2012 [Page 7]
Internet-Draft Data Model for CLUE June 2012 scene signifies a complete representation of the total scene. When there are multiple entries of the same media type in the capture scene, this means that each entry is an alternate representation of the total scene. Some elements of the capture-scene charactize the scene, as for example, capture-text. An entry is a list of video captures or a list of audio captures, and an indication of the switching policy. Every <entry> element contains the following child elements: o <capture-id> See above. o <switch-policy> text from framework. 4.12.1. <capture-scene-text> Text from framework 4.12.2. <capture-scene-language> Text from framework 4.12.3. <capture-scene-spatial-description> 4.12.3.1. <capture-scene-area> Indicates an overall encompassing co-ordinate "bounding box" at a per-capture set level. 4.12.3.2. capture-scene-scale> On a per-capture scene level, this indicates whether the co-ordinates used for its media captures are in real-world units, relative units, or whether no scale information can be inferred. 4.12.4. <future-capture-scene-attribute> This is a placeholder for capture set attributes that have yet to be defined. 4.13. <simultaneous transmission-set> Indicates physical simultaneity constraints. Use framework text. Every <entry> element contains the following child elements: Romanow & Pepperell Expires December 8, 2012 [Page 8]
Internet-Draft Data Model for CLUE June 2012 o <capture-id> As above 4.14. <stream-description> 4.14.1. <encoding> 4.14.1.1. <encoding-id> Use framework text. A unique value for the set of encoding parameters that constitute an encoding stream.. 4.14.1.2. < MULTIPLEX-ID> This element is the means by which the consumer, the receiver of a stream, tells the provider which multiplex id to generate that stream with, so that the consumer can demultiplex the stream correctly when receiving it. 4.14.1.3. <AUDIO-RENDERING-TAG> Optional id for rendering audio supplied by consumer to the provider. The provider then uses this tag to to associate an audio stream with a video stream. 4.14.1.4. <max-audio-bandwidth> This element gives the bandwidth limit for any audio strea. It can be used in provider advertisements with respect to potential streams, or in consumer request messages, describing a stream choice. 4.14.1.5. <max-video-bandwidth> This element gives the provider's bandwidth limit for any video stream. It can be used in provider advertisements with respect to potential streams, or in consumer request messages, describing a stream choice. 4.14.1.6. <max-H264-Mbps> This element gives the provider's maximum macroblock per second rate for any video stream. 4.14.1.7. <max-width> Framework text Romanow & Pepperell Expires December 8, 2012 [Page 9]
Internet-Draft Data Model for CLUE June 2012 4.14.1.8. <max-height> Framework text 4.14.1.9. <max-frame-rate> This element gives a maximum frame rate for a video stream. 4.14.1.10. <future-encoding-attribute> 4.14.2. <encoding-group> Encoding group is an element used by the provider to describe its capabilities. It groups together the potential encodings that are available for a particular capture. Therefore, a capture has associated with with it an encoding-id. Every <entry> element contains the following child elements: o A <video-encoding> is an encoding for video. o An <audio-encoding> is an encoding for audio. 4.14.2.1. <encoding-group-id> A unique id for the group of encodings that can be used for a particular capture. 4.14.2.2. <max-group-bandwidth> This indicates the maximum bandwidth that the provider can transmit for its combined set of active encodings. 4.14.2.3. <max-group-H264-Mbps> The maximum number of macroblocks per second that the provider can transmit for its combined set of active encodings. 4.14.2.4. <future-encoding-group-attribute> This is a placeholder for encoding group attributes that have yet to be defined. 5. Security Considerations TBD Romanow & Pepperell Expires December 8, 2012 [Page 10]
Internet-Draft Data Model for CLUE June 2012 6. IANA Considerations TBD 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, March 2012. 7.2. Informative References [I-D.ietf-clue-framework] Romanow, A., Duckworth, M., Pepperell, A., and B. Baldino, "Framework for Telepresence Multi-Streams", draft-ietf-clue-framework-05 (work in progress), May 2012. [I-D.lennox-clue-rtp-usage] Lennox, J., Witty, P., and A. Romanow, "Real-Time Transport Protocol (RTP) Usage for Telepresence Sessions", draft-lennox-clue-rtp-usage-04 (work in progress), June 2012. Authors' Addresses Allyn Romanow Cisco Systems San Jose, CA 95134 USA Email: allyn@cisco.com Andy Pepperell Silverflare Email: andy.pepperell@silverflare.com Romanow & Pepperell Expires December 8, 2012 [Page 11]