RTCWEB D. Burnett
Internet-Draft Voxeo
Intended status: Standards Track April 23, 2012
Expires: October 23, 2012

IANA Registry for RTCWeb Media Constraints
draft-burnett-rtcweb-constraints-registry-01

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 October 23, 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.


Table of Contents

1. Introduction

There are two W3C specifications that have need of a registry in which to represent constraints: getusermedia: Getting access to local devices that can generate multimedia streams [W3C.WD-getusermedia-2012xxxx] and WebRTC 1.0: Real-time Communication Between Browsers [W3C.WD-webrtc-20120209]. In the former, the getUserMedia() method on the NavigatorUserMedia interface takes an "options" argument (which may be renamed "constraints"). In the latter, the addMedia() method on the PeerConnection interface takes a "hints" parameter (soon to be renamed "constraints"). Both 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 also (will soon) define getCapabilities() methods that are used to query the web browser about its capabilities. The returned data structure specifies 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.

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 and a Reference (or list of references).

An RTCWeb Media Constraint Name MUST satisfy the following ABNF [RFC5234] specification:

rtcweb-media-constraint = media-type constraint-type constraint
media-type              = "audio" / "video"
constraint-type         = "Min" / "Max" / "Enum"
constraint              = %x41-5A 0*constraint-char
constraint-char         = ALPHA / DIGIT

Constraint names are case-sensitive.

A registration request MUST include the following information:

3.1.1. Designated Expert Instructions

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.

A constraint name with media-type of "audio" MUST be relevant to audio media streams and connections. 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 specification 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.

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-20120209] Bergkvist, A., Burnett, D., Jennings, C. and A. Narayanan, "WebRTC 1.0: Real-Time Communication Between Browsers", World Wide Web Consortium WD WD-webrtc-20120209, February 2012.
[W3C.WD-getusermedia-2012xxxx] Burnett, D. and A. Narayanan, "getusermedia: Getting access to local devices that can generate multimedia streams", World Wide Web Consortium WD WD-getusermedia-2012xxxx, XXX 2012.

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

Daniel C. Burnett Voxeo 189 South Orange Avenue #1000 Orlando, FL 32801 USA EMail: dburnett@voxeo.com