idnits 2.17.1 draft-walleij-ogg-mediatype-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2002) is 8014 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Walleij 3 Internet-Draft The Ogg Vorbis Community 4 Expires: November 10, 2002 May 2002 6 The application/ogg Media Type 7 draft-walleij-ogg-mediatype-06 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on November 10, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 The Ogg Bitstream Format aims at becoming a general freely-available 39 standard for transporting multimedia content across computing 40 platforms and networks. The intention of this document is to define 41 the media type application/ogg to refer to this kind of content when 42 transported across the Internet. It is the intention of the Ogg 43 Bitstream Format developers that it be usable without intellectual 44 property concerns. 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC 2119 [2]. 50 1. The Ogg Bitstream Format 52 The Ogg Bitstream format has been developed as a part of a larger 53 project aimed at creating a set of components for the coding and 54 decoding of multimedia content (codecs) which are to be freely 55 available and freely re-implementable both in software and in 56 hardware for the computing community at large, including the Internet 57 community. 59 Raw packets from these codecs may be used directly by transport 60 mechanisms that provide their own framing and packet-separation 61 mechanisms (such as UDP datagrams). 63 One such framing and content-separation mechanism is the real-time 64 transport protocol (RTP). RTP allows the streaming of syncronous 65 lossy data for broadcasting and similar purposes. Should this 66 functionality be desired, a separate RTP wrapping mechanism should be 67 used, and such a mechanism is currently under development. 69 For stream based storage (such as files) and transport (such as TCP 70 streams or pipes), Ogg codecs use the Ogg Bitstream Format to provide 71 framing/sync, sync recapture after error, landmarks during seeking, 72 and enough information to properly seperate data back into packets at 73 the original packet boundaries without relying on decoding to find 74 packet boundaries. The application/ogg MIME type refers to this kind 75 of bitstreams, when no further knowledge of the bitstream content 76 exists. 78 The bitstream format in itself is documented in [1]. 80 2. Registration Information 82 To: ietf-types@iana.org 84 Subject: Registration of MIME media type application/ogg 86 MIME media type name: application 88 MIME subtype name: ogg 90 Required parameters: none 92 Optional parameters: none 94 Encoding Considerations: 96 The Ogg bitstream format is binary data, and must be encoded for non- 97 binary transport; the Base64 encoding is suitable for Email, Binary 98 encoding could also be used. 100 Security Considerations: 102 As the Ogg bitstream file is a container format and only a carrier of 103 content (such as Vorbis audio) with a very rigid definition (see 104 [1]), this format in itself is not more vulnerable than any other 105 content framing mechanism. The main security consideration for the 106 receiving application is to ensure that manipulated packages can not 107 cause buffer overflows and the like. It is possible to encapsulate 108 even execuatble content in the bitstream, so for such uses additional 109 security considerations must be taken. 111 Ogg bitstream files are not signed or encrypted using any applicable 112 encryption schemes. External security mechanisms must be added if 113 content confidentiality and authenticity is to be achieved. 115 Interoperability considerations: 117 The Ogg bitstream format has proved to be widely implementable across 118 different computing platforms. A broadly portable reference 119 implementation is available under a BSD license. 121 The Ogg bitstream format is not patented and can be implemented by 122 third parties without patent considerations. 124 Published specification: 126 See [1]. 128 Applications which use this media type: 130 Any application that implements the specification will be able to 131 encode or decode Ogg bitstream files. Specifically, the format is 132 supposed to be used by subcodecs that implement for example Vorbis 133 audio. 135 Additional information: 137 Magic number(s): 139 In Ogg bitstream files, the first four bytes are 0x4f 0x67 0x67 0x53 140 corresponding to the string "OggS". 142 File extension: .ogg 144 Macintosh File Type Code(s): OggS 146 Object Identifier(s) or OID(s): none 148 Person & email address to contact for further information: 150 Questions about this proposal should be directed to Linus Walleij 151 . Technical questions about the Ogg bitstream 152 standard may be asked on the mailing lists for the developer 153 community. 155 Intended usage: COMMON 157 Author/Change controller: 159 This document was written by Linus Walleij , changes 160 of this document will be handled by him or a representative of the 161 Xiph.org or the associated development communities. 163 The Ogg bitstream format is controlled by the Xiph.org and the 164 respective development communities. 166 3. Security Considerations 168 Security considerations are discussed in the security considerations 169 clause of the MIME registration in section 2. 171 References 173 [1] The Xiph.org, , "Ogg logical and physical bitstream overview", 174 June 2001, . 176 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 177 Levels", BCP 14, RFC 2119, March 1997. 179 Author's Address 181 Linus Walleij 182 The Ogg Vorbis Community 183 Master Olofs Vag 24 184 Lund 224 66 185 SE 187 Phone: +46 703 193678 188 EMail: triad@df.lth.se 189 URI: http://www.xiph.org/ 191 Full Copyright Statement 193 Copyright (C) The Internet Society (2002). All Rights Reserved. 195 This document and translations of it may be copied and furnished to 196 others, and derivative works that comment on or otherwise explain it 197 or assist in its implementation may be prepared, copied, published 198 and distributed, in whole or in part, without restriction of any 199 kind, provided that the above copyright notice and this paragraph are 200 included on all such copies and derivative works. However, this 201 document itself may not be modified in any way, such as by removing 202 the copyright notice or references to the Internet Society or other 203 Internet organizations, except as needed for the purpose of 204 developing Internet standards in which case the procedures for 205 copyrights defined in the Internet Standards process must be 206 followed, or as required to translate it into languages other than 207 English. 209 The limited permissions granted above are perpetual and will not be 210 revoked by the Internet Society or its successors or assigns. 212 This document and the information contained herein is provided on an 213 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 214 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 215 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 216 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 217 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 219 Acknowledgement 221 Funding for the RFC Editor function is currently provided by the 222 Internet Society.