idnits 2.17.1 draft-levine-application-gzip-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 3 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2012) is 4423 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.R. Levine 3 Internet-Draft Taughannock Networks 4 Intended status: Informational March 2012 5 Expires: September 12, 2012 7 The application/zlib and application/gzip media types 8 draft-levine-application-gzip-01 10 Abstract 12 This document defines the 'application/gzip' and 'application/zlib' 13 media types for compressed data using the gzip and zlib compression 14 formats. 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 September 12, 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 1. Introduction 49 The Zlib [RFC1950] and gzip [RFC1952] formats are widely used 50 compression formats. Zlib is a stream format, while glib adds header 51 and trailer fields more appropriate for a file format. Both 52 implement the DEFLATE compression scheme described in [RFC1951]. 54 They are used to compress a wide variety of material, from 55 unstructured text to structured data to executable code. 57 Some applications have informally used the media type application/ 58 x-gzip. The media types defined in this document should replace that 59 media type in future applications. 61 2. The Application/Zlib Media Type 63 The application/zlib media type describes a block of data that is 64 compressed using Zlib [RFC1950] compression. The data is a stream of 65 bytes as described in RFC 1950. 67 2.1. Regsistration Details 69 Type name: application 71 Subtype name: zlib 73 Required parameters: N/A 75 Optional parameters: N/A 77 Encoding considerations: needs base64 or other encoding that allows 78 arbitrary binary data 80 Security considerations: See section [security] below 82 Interoperability considerations: N/A 84 Published specification: [RFC1950] 86 Applications that use this media type: anywhere data size is an issue 88 Additional information: 90 Magic number(s): first byte is usually 0x78 but can also be 0x08, 91 0x18, 0x28, 0x38, 0x48, 0x58, or 0x68. 92 File extension(s): N/A 93 Macintosh file type code(s): N/A 95 Person and email address to contact for further information: see 96 http://www.zlib.net/ 98 Intended usage: COMMON 100 Restrictions on usage: N/A 102 Author: John Levine 104 Change controller: IETF 106 3. The Application/Gzip Media Type 107 The application/gzip media type describes a block of data that is 108 compressed using gzip [RFC1952] compression. The data is a stream of 109 bytes as described in RFC 1952. 111 3.1. Regsistration Details 113 Type name: application 115 Subtype name: gzip 117 Required parameters: N/A 119 Optional parameters: N/A 121 Encoding considerations: needs base64 or other encoding that allows 122 arbitrary binary data 124 Security considerations: See section [security] below 126 Interoperability considerations: N/A 128 Published specification: [RFC1952] 130 Applications that use this media type: anywhere data size is an issue 132 Additional information: 134 Magic number(s): first two bytes are 0x1f, 0x8b. 135 File extension(s): gz 136 Macintosh file type code(s): N/A 138 Person and email address to contact for further information: see 139 http://www.gzip.net/ 141 Intended usage: COMMON 143 Restrictions on usage: N/A 145 Author: John Levine 147 Change controller: IETF 149 4. Security Considerations 151 Zlib and gzip compression can be used to compress arbitrary binary 152 data such as hostile executable code. Also, data that purports to be 153 in zlib or gzip format may not be, and fields that are supposed to be 154 flags, lengths, or pointers, could contain anything. Applications 155 should treat any data with due scepticism. 157 Also see the security considerations in the underlying format 158 documents, Section 5 of [RFC1950], Section 6 of [RFC1951], and 159 Section 4 of [RFC1952]. 161 5. References 163 [RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data 164 Format Specification version 3.3", RFC 1950, May 1996. 166 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 167 version 1.3", RFC 1951, May 1996. 169 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L.P. and G. 170 Randers-Pehrson, "GZIP file format specification version 171 4.3", RFC 1952, May 1996. 173 Appendix A. Change log 175 Note to editor: Please remove this section before publication. 177 Appendix A.1. Changes from -00 to -01 179 Note former x-gzip 181 Refer to security sections in underlying format docs 183 Author's Address 185 John Levine 186 Taughannock Networks 187 PO Box 727 188 Trumansburg, NY 14886 190 Phone: +1 831 480 2300 191 Email: standards@taugh.com