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

RTCWEB                                                        D. Burnett
Internet-Draft                                                     Voxeo
Intended status: Standards Track                           March 2, 2012
Expires: September 3, 2012

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

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 September 3, 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.

Burnett                 Expires September 3, 2012               [Page 1]
Internet-Draft            constraints-registry                March 2012

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
     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 . . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6

Burnett                 Expires September 3, 2012               [Page 2]
Internet-Draft            constraints-registry                March 2012

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).

Burnett                 Expires September 3, 2012               [Page 3]
Internet-Draft            constraints-registry                March 2012

   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              = ALPHA 0*constraint-char
 constraint-char         = ALPHA / DIGIT / "-"

   Constraint names are case-sensitive.

   A registration request MUST include the following information:

   o  The constraint name to be registered
   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

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

Burnett                 Expires September 3, 2012               [Page 4]
Internet-Draft            constraints-registry                March 2012

         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,
              <http://www.w3.org/TR/2012/WD-webrtc-20120209>.

   [W3C.WD-getusermedia-2012xxxx]

Burnett                 Expires September 3, 2012               [Page 5]
Internet-Draft            constraints-registry                March 2012

              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,
              <http://www.w3.org/TR/2012/WD-getusermedia-2012xxxx>.

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

Burnett                 Expires September 3, 2012               [Page 6]