idnits 2.17.1 draft-walleij-ogg-mediatype-05.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 (Feb 2002) is 8098 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: August 2, 2002 Feb 2002 6 The application/ogg Media Type 7 draft-walleij-ogg-mediatype-05 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 August 2, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 The Ogg Bitstream Format aim at becoming a general patent-free 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. 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119 [2]. 48 1. The Ogg Bitstream Format 50 The Ogg Bitstream format has been developed as a part of a larger 51 project aimed at creating a set of components for the coding and 52 decoding of multimedia content (codecs) which are to be freely 53 available and freely re-implementable both in software and in 54 hardware for the computing community at large, including the Internet 55 community. 57 Raw packets from these codecs may be used directly by transport 58 mechanisms that provide their own framing and packet-separation 59 mechanisms (such as UDP datagrams). 61 One such framing and content-separation mechanism is the real-time 62 transport protocol (RTP). RTP allows the streaming of syncronous 63 lossy data for broadcasting and similar purposes. Should this 64 functionality be desired, a separate RTP wrapping mechanism should be 65 used, and such a mechanism is currently under development. 67 For stream based storage (such as files) and transport (such as TCP 68 streams or pipes), Ogg codecs use the Ogg Bitstream Format to provide 69 framing/sync, sync recapture after error, landmarks during seeking, 70 and enough information to properly seperate data back into packets at 71 the original packet boundaries without relying on decoding to find 72 packet boundaries. The application/ogg MIME type refers to this kind 73 of bitstreams, when no further knowledge of the bitstream content 74 exists. 76 The bitstream format in itself is documented in [1]. 78 2. Registration Information 80 To: ietf-types@iana.org 82 Subject: Registration of MIME media type application/ogg 84 MIME media type name: application 86 MIME subtype name: ogg 88 Required parameters: none 90 Optional parameters: none 92 Encoding Considerations: 94 The Ogg bitstream format is binary data, and must be encoded for non- 95 binary transport; the Base64 encoding is suitable for Email, Binary 96 encoding could also be used. 98 Security Considerations: 100 As the Ogg bitstream file is a container format and only a carrier of 101 content (such as Vorbis audio) with a very rigid definition (see 102 [1]), this format in itself is not more vulnerable than any other 103 content framing mechanism. The main security consideration for the 104 receiving application is to ensure that manipulated packages can not 105 cause buffer overflows and the like. It is possible to encapsulate 106 even execuatble content in the bitstream, so for such uses additional 107 security considerations must be taken. 109 Ogg bitstream files are not signed or encrypted using any applicable 110 encryption schemes. External security mechanisms must be added if 111 content confidentiality and authenticity is to be achieved. 113 Interoperability considerations: 115 The Ogg bitstream format has proved to be widely implementable across 116 different computing platforms. A broadly portable reference 117 implementation is available under a BSD license. 119 The Ogg bitstream format is not patented and can be implemented by 120 third parties without patent considerations. 122 Published specification: 124 See [1]. 126 Applications which use this media type: 128 Any application that implements the specification will be able to 129 encode or decode Ogg bitstream files. Specifically, the format is 130 supposed to be used by subcodecs that implement for example Vorbis 131 audio. 133 Additional information: 135 Magic number(s): 137 In Ogg bitstream files, the first four bytes are 0x4f 0x67 0x67 0x53 138 corresponding to the string "OggS". 140 File extension: .ogg 142 Macintosh File Type Code(s): OggS 144 Object Identifier(s) or OID(s): none 146 Person & email address to contact for further information: 148 Questions about this proposal should be directed to Linus Walleij 149 . Technical questions about the Ogg bitstream 150 standard may be asked on the mailing lists for the developer 151 community. 153 Intended usage: COMMON 155 Author/Change controller: 157 This document was written by Linus Walleij , changes 158 of this document will be handled by him or a representative of the 159 Xiph.org or the associated development communities. 161 The Ogg bitstream format is controlled by the Xiph.org and the 162 respective development communities. 164 3. Security Considerations 166 Security considerations are discussed in the security considerations 167 clause of the MIME registration in section 2. 169 References 171 [1] The Xiph.org, , "Ogg logical and physical bitstream overview", 172 June 2001, . 174 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 175 Levels", BCP 14, RFC 2119, March 1997. 177 Author's Address 179 Linus Walleij 180 The Ogg Vorbis Community 181 Master Olofs Vag 24 182 Lund 224 66 183 SE 185 Phone: +46 703 193678 186 EMail: triad@df.lth.se 187 URI: http://www.xiph.org/ 189 Full Copyright Statement 191 Copyright (C) The Internet Society (2002). All Rights Reserved. 193 This document and translations of it may be copied and furnished to 194 others, and derivative works that comment on or otherwise explain it 195 or assist in its implementation may be prepared, copied, published 196 and distributed, in whole or in part, without restriction of any 197 kind, provided that the above copyright notice and this paragraph are 198 included on all such copies and derivative works. However, this 199 document itself may not be modified in any way, such as by removing 200 the copyright notice or references to the Internet Society or other 201 Internet organizations, except as needed for the purpose of 202 developing Internet standards in which case the procedures for 203 copyrights defined in the Internet Standards process must be 204 followed, or as required to translate it into languages other than 205 English. 207 The limited permissions granted above are perpetual and will not be 208 revoked by the Internet Society or its successors or assigns. 210 This document and the information contained herein is provided on an 211 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 212 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 213 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 214 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 215 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 217 Acknowledgement 219 Funding for the RFC Editor function is currently provided by the 220 Internet Society.