Internet DRAFT - draft-romanow-clue-data-model
draft-romanow-clue-data-model
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]
