idnits 2.17.1 draft-walleij-ogg-mediatype-01.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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages 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 == Line 123 has weird spacing: '...used by codec...' == 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 22, 2001) is 8367 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 (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Walleij 2 Internet-Draft The Ogg Vorbis Community 3 Expires: November 20, 2001 May 22, 2001 5 The application/ogg Media Type 6 draft-walleij-ogg-mediatype-01 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on November 17, 2001. 31 Copyright Notice 33 Copyright (C) The Internet Society (2001). All Rights Reserved. 35 Abstract 37 The Ogg Bitstream Format aim at becoming a general patent-free 38 standard for transporting multimedia content across computing 39 platforms and networks. The intention of this document is to define 40 the media type application/ogg to refer to this kind of content when 41 transported across the Internet. 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC 2119 [2]. 47 1. The Ogg Bitstream Format 49 The Ogg Bitstream format has been developed as a part of a larger 50 project aimed at creating a set of compenents for the coding and 51 decoding of multimedia content (codecs) which are to be freely 52 available and freely re-implementable both in software and in 53 hardware for the computing community at large, including the 54 Internet community. 56 Raw packets from these codecs may be used directly by transport 57 mechanisms that provide their own framing and packet-seperation 58 mechanisms (such as UDP datagrams). 60 For stream based storage (such as files) and transport (such as TCP 61 streams or pipes), Ogg codecs use the Ogg Bitstream Format to 62 provide framing/sync, sync recapture after error, landmarks during 63 seeking, and enough information to properly seperate data back into 64 packets at the original packet boundaries without relying on decoding 65 to find packet boundaries. The application/ogg MIME type refers to 66 this kind of bitstreams, when no further knowledge of the bitstream 67 content exists. 69 The bitstream format in itself is documented in [1]. 71 2. Registration Information 73 To: ietf-types@iana.org 75 Subject: Registration of MIME media type application/ogg 77 MIME media type name: application 79 MIME subtype name: ogg 81 Required parameters: none 83 Optional parameters: none 85 Encoding Considerations: 87 The Ogg bitstream format is binary data, and must be encoded for non- 88 binary transport; the Base64 encoding is suitable for Email, Binary 89 encoding could also be used. 91 Security Considerations: 93 As the Ogg bitstream file is a container format and only a carrier of 94 content (such as Vorbis audio) with a very rigid definition (see 95 [1]), this format in itself is not more vulnerable than any other 96 content framing mechanism. The main security consideration for the 97 receiving application is to ensure that manipulated packages can not 98 cause buffer overflows and the like. It is possible to encapsulate 99 even execuatble content in the bitstream, so for such uses additional 100 security considerations must be taken. 102 Ogg bitstream files are not signed or encrypted using any applicable 103 encryption schemes. External security mechanisms must be added if 104 content confidentiality and authenticity is to be achieved. 106 Interoperability considerations: 108 The Ogg bitstream format has proved to be widely implementable across 109 different computing platforms. A broadly portable reference 110 implementation is available under a BSD license. 112 The Ogg bitstream format is not patented and can be implemented by 113 third parties without patent considerations. 115 Published specification: 117 See [1]. 119 Applications which use this media type: 121 Any application that implements the specification will be able to 122 encode or decode Ogg bitstream files. Specifically, the format is 123 supposed to be used by codecs that implement for example Vorbis 124 audio. 126 Additional information: 128 Magic number(s): 130 In Ogg bitstream files, the first four bytes are 0x4f 0x67 0x67 0x53 131 corresponding to the string "OggS". 133 File extension: .ogg 135 Macintosh File Type Code(s): OggS 137 Object Identifier(s) or OID(s): none 139 Person & email address to contact for further information: 141 Questions about this proposal should be directed to Linus Walleij 142 . Technical questions about the Ogg bitstream 143 standard may be asked on the mailing lists for the developer 144 community. 146 Intended usage: COMMON 148 Author/Change controller: 150 This document was written by Linus Walleij , changes 151 of this document will be handled by him or a representative of the 152 Xiphophorus company or the associated development communities. 154 The Ogg bitstream format is controlled by the Xiphophorus company and 155 the respective development communities. 157 3. Security Considerations 159 Security considerations are discussed in the security considerations 160 clause of the MIME registration in section 2. 162 References 164 [1] The Xiphophorous Company, "Ogg logical and physical 165 bitstream overview", June 2001, 166 . 168 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 169 Levels", BCP 14, RFC 2119, March 1997. 171 Author's Address 173 Linus Walleij 174 The Ogg Vorbis Community 175 Master Olofs Vag 24 176 Lund 224 66 177 SE 179 Phone: +46 703 193678 180 EMail: triad@df.lth.se 181 URI: http://www.xiph.org/ 183 Full Copyright Statement 185 Copyright (C) The Internet Society (2001). All Rights Reserved. 187 This document and translations of it may be copied and furnished to 188 others, and derivative works that comment on or otherwise explain it 189 or assist in its implementation may be prepared, copied, published 190 and distributed, in whole or in part, without restriction of any 191 kind, provided that the above copyright notice and this paragraph are 192 included on all such copies and derivative works. However, this 193 document itself may not be modified in any way, such as by removing 194 the copyright notice or references to the Internet Society or other 195 Internet organizations, except as needed for the purpose of 196 developing Internet standards in which case the procedures for 197 copyrights defined in the Internet Standards process must be 198 followed, or as required to translate it into languages other than 199 English. 201 The limited permissions granted above are perpetual and will not be 202 revoked by the Internet Society or its successors or assigns. 204 This document and the information contained herein is provided on an 205 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 206 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 207 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 208 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 209 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 211 Acknowledgement 213 Funding for the RFC Editor function is currently provided by the 214 Internet Society.