idnits 2.17.1 draft-ietf-rtcweb-constraints-registry-02.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: ---------------------------------------------------------------------------- No issues found here. 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 (March 9, 2015) is 3333 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 (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTCWEB D. Burnett 3 Internet-Draft Aspect Software, Inc. 4 Intended status: Standards Track March 9, 2015 5 Expires: September 10, 2015 7 IANA Registry for RTCWeb Constrainable Properties 8 draft-ietf-rtcweb-constraints-registry-02 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 14 constrainable properties for HTML media and other constrainable 15 objects. This document defines this registry. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 10, 2015. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 53 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 2 54 3.1. RTCWeb Constrainable Properties . . . . . . . . . . . . . 3 55 3.1.1. Designated Expert Instructions . . . . . . . . . . . 3 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 59 5.2. Informative References . . . . . . . . . . . . . . . . . 4 60 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1. Introduction 65 There is currently one W3C specification (Media Capture and Streams 66 [W3C.WD-mediacapture-streams-20150212]) that has need of a registry 67 in which to represent constrainable properties, and it is expected 68 that others will as well. The specification makes use of a data 69 structure representing a list of constraints on the HTML media or 70 media connection to be established. Additionally, the specification 71 defines methods that are used to query the web browser about its 72 capabilities. The returned data structure specifies the browser's 73 capabilities in terms of constraints that it can satisfy. The data 74 structures and their use are defined as the Constrainable Pattern in 75 the aforementioned specification. This document specifies the 76 registry used to define individual constrainable property names, 77 their allowed values, and their meanings. 79 2. Requirements Language 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [RFC2119]. 85 3. IANA Considerations 87 This document defines a registry "RTCWeb Constrainable Properties" 88 for use by W3C specifications needing to indicate constrainable 89 properties on HTML Media and other constrainable objects, both as 90 used by web application authors to indicate preferences and as used 91 by web browsers to indicate constrainable properties they can 92 satisfy. 94 3.1. RTCWeb Constrainable Properties 96 IANA SHALL create a new name space of "RTCWeb Constrainable 97 Properties". All maintenance within and additions to the contents of 98 this name space MUST be according to the "Specification Required with 99 Expert Review" registration policy as defined in RFC5226 [RFC5226]. 100 The registry is initially empty. The registry is defined in the 101 remainder of this section. 103 Each registry entry consists of a Name and a Reference (or list of 104 references). 106 An RTCWeb Constrainable Property Name MUST satisfy the following ABNF 107 [RFC5234] specification: 109 rtcweb-constrainable-property = constrainable-property-name 110 constrainable-property-name = %x41-5A 0*constraint-char 111 constraint-char = ALPHA / DIGIT 113 RTCWeb Constrainable Property Names are case-sensitive. 115 A registration request MUST include the following information: 117 o The RTCWeb Constrainable Property Name to be registered 119 o Name and Email address of a contact person for the registration 121 o Organization or individuals having the change control 123 o Reference(s) to the specification(s) defining the property 125 3.1.1. Designated Expert Instructions 127 RTCWeb Constrainable Property Names are of unlimited length according 128 to the syntax. However, it is RECOMMENDED that they be no longer 129 than 80 characters in total. This is to keep them reasonable for 130 humans to read and use. It is RECOMMENDED that Names use camel case, 131 i.e., when a Name consists of multiple words, the first character of 132 each word SHOULD be an uppercase character, with all others being 133 lowercase. 135 The References MUST define the following for each RTCWeb 136 Constrainable Property: 138 allowed values 139 The References MUST define the allowed values for the property, 140 for example an enumerated list of values or a range of 141 integers. 143 object(s) 144 The References MUST define the object or objects for which the 145 properties apply, for example a MediaStreamTrack. 147 The RTCWeb Constrainable Property MUST be well enough defined in the 148 given References that it is understandable by implementors and 149 application developers that will use the property. The property 150 SHOULD NOT duplicate a condition that can be achieved using 151 properties already defined in the registry. The property Name SHOULD 152 be appropriate and specific enough for the property. 154 4. Security Considerations 156 Since the constrainable properties envisioned for this registry are 157 fairly generic in nature, it is not expected that the mere existence 158 of this registry will introduce any particular security issues. Any 159 specification defining one or more new properties SHOULD address any 160 specific security issues that might be introduced by the properties 161 or their constrainable values. 163 5. References 165 5.1. Normative References 167 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 168 Requirement Levels", BCP 14, RFC 2119, March 1997. 170 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 171 Specifications: ABNF", STD 68, RFC 5234, January 2008. 173 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 174 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 175 May 2008. 177 5.2. Informative References 179 [W3C.WD-mediacapture-streams-20150212] 180 Burnett, D., Bergkvist, A., Jennings, C., and A. 181 Narayanan, "Media Capture and Streams", World Wide Web 182 Consortium WD WD-mediacapture-streams-20150212, February 183 2015, . 186 Appendix A. Acknowledgements 188 The authors would like to thank the members of the W3C Media Capture 189 Task Force and WebRTC Working Group, the members of the IETF RTCWEB 190 Working Group, and the people who gave specific early review and 191 feedback: Cullen Jennings and Travis Leithead. 193 Author's Address 195 Daniel C. Burnett 196 Aspect Software, Inc. 197 189 South Orange Ave. #1000 198 Orlando, FL 32801 199 USA 201 Email: dburnett@voxeo.com