idnits 2.17.1 draft-burnett-rtcweb-constraints-registry-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 23, 2012) is 4384 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB D. Burnett 3 Internet-Draft Voxeo 4 Intended status: Standards Track April 23, 2012 5 Expires: October 23, 2012 7 IANA Registry for RTCWeb Media Constraints 8 draft-burnett-rtcweb-constraints-registry-01 10 Abstract 12 Specifications in W3C's Media Capture Task Force and WebRTC Working 13 Group have need of a registry in which to maintain a list of HTML 14 Media constraints. This document defines this registry. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on October 23, 2012. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 51 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 2 52 3.1. RTCWeb Media Constraints . . . . . . . . . . . . . . . . . 2 53 3.1.1. Designated Expert Instructions . . . . . . . . . . . . 3 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5.1. Normative References . . . . . . . . . . . . . . . . . . . 4 58 5.2. Informative References . . . . . . . . . . . . . . . . . . 4 59 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 4 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1. Introduction 64 There are two W3C specifications that have need of a registry in 65 which to represent constraints: getusermedia: Getting access to local 66 devices that can generate multimedia streams [W3C.WD-getusermedia- 67 2012xxxx] and WebRTC 1.0: Real-time Communication Between Browsers 68 [W3C.WD-webrtc-20120209]. In the former, the getUserMedia() method 69 on the NavigatorUserMedia interface takes an "options" argument 70 (which may be renamed "constraints"). In the latter, the addMedia() 71 method on the PeerConnection interface takes a "hints" parameter 72 (soon to be renamed "constraints"). Both of these parameters make use 73 of a data structure representing a list of constraints on the HTML 74 media or media connection to be established. Additionally, both 75 specifications also (will soon) define getCapabilities() methods that 76 are used to query the web browser about its capabilities. The 77 returned data structure specifies the browser's capabilities in terms 78 of constraints that it can satisfy. The data structures and their 79 use are defined in the aforementioned specifications. This document 80 specifies the registry used to define individual constraint names, 81 their allowed values, and their meanings. 83 2. Requirements Language 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [RFC2119]. 89 3. IANA Considerations 91 This document defines a registry "RTCWeb Media Constraints" for use 92 by W3C specifications needing to indicate constraints on HTML Media, 93 both as used by web application authors to indicate preferences and 94 as used by web browsers to indicate constraints they can satisfy. 96 3.1. RTCWeb Media Constraints 98 IANA SHALL create a new name space of "RTCWeb Media Constraints". 99 All maintenance within and additions to the contents of this name 100 space MUST be according to the "Specification Required with Expert 101 Review" registration policy as defined in RFC5226 [RFC5226]. The 102 registry is initially empty. The registry is defined in the 103 remainder of this section. 105 Each registry entry consists of a Name and a Reference (or list of 106 references). 108 An RTCWeb Media Constraint Name MUST satisfy the following ABNF 109 [RFC5234] specification: 111 rtcweb-media-constraint = media-type constraint-type constraint 112 media-type = "audio" / "video" 113 constraint-type = "Min" / "Max" / "Enum" 114 constraint = %x41-5A 0*constraint-char 115 constraint-char = ALPHA / DIGIT 117 Constraint names are case-sensitive. 119 A registration request MUST include the following information: 121 o The constraint name to be registered 122 o Name and Email address of a contact person for the registration 123 o Organization or individuals having the change control 124 o Reference(s) to the specification(s) defining the constraint 126 3.1.1. Designated Expert Instructions 128 Constraint names are of unlimited length according to the syntax. 129 However, it is RECOMMENDED that they be no longer than 80 characters 130 in total. This is to keep them reasonable for humans to read and 131 use. 133 A constraint name with media-type of "audio" MUST be relevant to 134 audio media streams and connections. A constraint of media-type 135 "video" MUST be relevant to video media streams and connections. 137 A constraint MUST satisfy the following criteria based upon its 138 constraint-type: 140 min 141 When used by a web application author, the constraint MUST 142 represent the minimum value the author is willing to accept. 143 When returned by a web browser as a capability, the constraint 144 MUST represent the minimum value that the web browser could 145 satisfy if requested to by the web application author. The 146 constraint specification MUST clearly define the units 147 associated with the value if the value itself does not specify 148 them. 149 max 150 When used by a web application author, the constraint MUST 151 represent the maximum value the author is willing to accept. 152 When returned by a web browser as a capability, the constraint 153 MUST represent the maximum value that the web browser could 154 satisfy if requested to by the web application author. The 155 constraint specification MUST clearly define the units 156 associated with the value if the value itself does not specify 157 them. 158 enum 159 The constraint specification MUST enumerate all allowed values. 161 The constraint MUST be well enough defined in the specification that 162 it is understandable by implementors and application developers that 163 will use the constraint. The constraint SHOULD NOT duplicate a 164 condition that can be achieved using constraints already defined in 165 the registry. The constraint name SHOULD be appropriate and specific 166 enough for the constraint. 168 4. Security Considerations 170 Since the constraints envisioned for this registry are fairly generic 171 in nature, it is not expected that the mere existence of this 172 registry will introduce any particular security issues. Any 173 specification defining one or more new constraints SHOULD address any 174 specific security issues that might be introduced by the 175 constraint(s). 177 5. References 179 5.1. Normative References 181 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 182 Requirement Levels", BCP 14, RFC 2119, March 1997. 184 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 185 Specifications: ABNF", STD 68, RFC 5234, January 2008. 187 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 188 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 189 May 2008. 191 5.2. Informative References 193 [W3C.WD-webrtc-20120209] 194 Bergkvist, A., Burnett, D., Jennings, C. and A. Narayanan, 195 "WebRTC 1.0: Real-Time Communication Between Browsers", 196 World Wide Web Consortium WD WD-webrtc-20120209, February 197 2012, . 199 [W3C.WD-getusermedia-2012xxxx] 200 Burnett, D. and A. Narayanan, "getusermedia: Getting 201 access to local devices that can generate multimedia 202 streams", World Wide Web Consortium WD WD-getusermedia- 203 2012xxxx, XXX 2012, . 206 Appendix A. Acknowledgements 208 The authors would like to thank the members of the W3C Media Capture 209 Task Force and WebRTC Working Group, the members of the IETF RTCWEB 210 Working Group, and the people who gave specific early review and 211 feedback: Cullen Jennings and Travis Leithead. 213 Author's Address 214 Daniel C. Burnett 215 Voxeo 216 189 South Orange Avenue #1000 217 Orlando, FL 32801 218 USA 220 Email: dburnett@voxeo.com