RTCWEB D. Burnett
Internet-Draft Voxeo
Intended status: Standards Track July 15, 2013
Expires: January 16, 2014
IANA Registry for RTCWeb Media Constraints
draft-burnett-rtcweb-constraints-registry-03
Abstract
Specifications in W3C's Media Capture Task Force and WebRTC Working
Group have need of a registry in which to maintain a list of HTML
media constraints. This document defines this registry.
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 January 16, 2014.
Copyright Notice
Copyright (c) 2013 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.
Burnett Expires January 16, 2014 [Page 1]
Internet-Draft constraints-registry July 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 2
3.1. RTCWeb Media Constraints . . . . . . . . . . . . . . . . 3
3.1.1. Designated Expert Instructions . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
There are two W3C specifications that have need of a registry in
which to represent constraints: Media Capture and Streams
[W3C.WD-mediacapture-streams-20120628] and WebRTC 1.0: Real-time
Communication Between Browsers [W3C.WD-webrtc-20120821]. In the
former, the getUserMedia() method on the NavigatorUserMedia interface
takes a "constraints" argument. In the latter, the addStream()
method on the RTCPeerConnection interface and the constructor for
RTCPeerConnection both take optional "constraints" parameters. All
three of these parameters make use of a data structure representing a
list of constraints on the HTML media or media connection to be
established. Additionally, both specifications may at some point
define getCapabilities() methods that are used to query the web
browser about its capabilities. It is possible that the returned
data structure will specify the browser's capabilities in terms of
constraints that it can satisfy. The data structures and their use
are defined in the aforementioned specifications. This document
specifies the registry used to define individual constraint names,
their allowed values, and their meanings.
2. Requirements Language
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].
3. IANA Considerations
This document defines a registry "RTCWeb Media Constraints" for use
by W3C specifications needing to indicate constraints on HTML Media,
both as used by web application authors to indicate preferences and
as used by web browsers to indicate constraints they can satisfy.
Burnett Expires January 16, 2014 [Page 2]
Internet-Draft constraints-registry July 2013
3.1. RTCWeb Media Constraints
IANA SHALL create a new name space of "RTCWeb Media Constraints".
All maintenance within and additions to the contents of this name
space MUST be according to the "Specification Required with Expert
Review" registration policy as defined in RFC5226 [RFC5226]. The
registry is initially empty. The registry is defined in the
remainder of this section.
Each registry entry consists of a Name, a Media Type, and a Reference
(or list of references).
An RTCWeb Media Constraint Name MUST satisfy the following ABNF
[RFC5234] specification:
rtcweb-media-constraint = constraint-type constraint
constraint-type = "min" / "max" / "enum"
constraint = %x41-5A 0*constraint-char
constraint-char = ALPHA / DIGIT
RTCWeb Media Constraint Names are case-sensitive.
The Media Type MUST be one of the values as specified by the
following ABNF specification:
rtcweb-media-type = "audio" / "video" / "RTCPeerConnection"
A registration request MUST include the following information:
o The RTCWeb Media Constraint Name to be registered
o The applicable Media Type for the Name
o Name and Email address of a contact person for the registration
o Organization or individuals having the change control
o Reference(s) to the specification(s) defining the constraint
Burnett Expires January 16, 2014 [Page 3]
Internet-Draft constraints-registry July 2013
3.1.1. Designated Expert Instructions
RTCWeb Media Constraint Names are of unlimited length according to
the syntax. However, it is RECOMMENDED that they be no longer than
80 characters in total. This is to keep them reasonable for humans
to read and use. It is RECOMMENDED that Names use camel case, i.e.,
when a Name consists of multiple words, the first character of each
word SHOULD be an uppercase character, with all others being
lowercase. This recommendation only applies to the characters
following the constraint-type.
An RTCWeb Constraint MUST be relevant for the Media Type given. For
example, a Constraint with Media Type of "audio" MUST be relevant to
audio media streams and connections, while a Constraint of Media Type
"video" MUST be relevant to video media streams and connections.
A constraint MUST satisfy the following criteria based upon its
constraint-type:
min
When used by a web application author, the constraint MUST
represent the minimum value the author is willing to accept.
When returned by a web browser as a capability, the constraint
MUST represent the minimum value that the web browser could
satisfy if requested to by the web application author. The
constraint specification MUST clearly define the units
associated with the value if the value itself does not specify
them.
max
When used by a web application author, the constraint MUST
represent the maximum value the author is willing to accept.
When returned by a web browser as a capability, the constraint
MUST represent the maximum value that the web browser could
satisfy if requested to by the web application author. The
constraint specification MUST clearly define the units
associated with the value if the value itself does not specify
them.
enum
The constraint specification MUST enumerate all allowed values.
The constraint MUST be well enough defined in the given references
that it is understandable by implementors and application developers
that will use the constraint. The constraint SHOULD NOT duplicate a
condition that can be achieved using constraints already defined in
the registry. The constraint name SHOULD be appropriate and specific
enough for the constraint.
Burnett Expires January 16, 2014 [Page 4]
Internet-Draft constraints-registry July 2013
4. Security Considerations
Since the constraints envisioned for this registry are fairly generic
in nature, it is not expected that the mere existence of this
registry will introduce any particular security issues. Any
specification defining one or more new constraints SHOULD address any
specific security issues that might be introduced by the
constraint(s).
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
5.2. Informative References
[W3C.WD-webrtc-20120821]
Bergkvist, A., Burnett, D., Jennings, C., and A.
Narayanan, "WebRTC 1.0: Real-Time Communication Between
Browsers", World Wide Web Consortium WD WD-
webrtc-20120821, August 2012,
<http://www.w3.org/TR/2012/WD-webrtc-20120821>.
[W3C.WD-mediacapture-streams-20120628]
Burnett, D. and A. Narayanan, "Media Capture and Streams",
World Wide Web Consortium WD WD-mediacapture-
streams-20120628, June 2012, <http://www.w3.org/TR/2012/
WD-mediacapture-streams-20120628/>.
Appendix A. Acknowledgements
The authors would like to thank the members of the W3C Media Capture
Task Force and WebRTC Working Group, the members of the IETF RTCWEB
Working Group, and the people who gave specific early review and
feedback: Cullen Jennings and Travis Leithead.
Author's Address
Burnett Expires January 16, 2014 [Page 5]
Internet-Draft constraints-registry July 2013
Daniel C. Burnett
Voxeo
189 South Orange Avenue #1000
Orlando, FL 32801
USA
Email: dburnett@voxeo.com
Burnett Expires January 16, 2014 [Page 6]