idnits 2.17.1 draft-levine-application-gzip-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: ---------------------------------------------------------------------------- == 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 (April 2012) is 4394 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 April 2012 5 Expires: October 13, 2012 7 The application/zlib and application/gzip media types 8 draft-levine-application-gzip-02 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 October 13, 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 gzip 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 media types including 58 application/gzip-compressed, application/gzipped, application/ 59 x-gunzip, application/x-gzip, application/x-gzip-compressed, and gzip 60 /document to describe data compressed with gzip. The media types 61 defined in this document should replace those media types in future 62 applications. 64 2. The Application/Zlib Media Type 66 The application/zlib media type describes a block of data that is 67 compressed using Zlib [RFC1950] compression. The data is a stream of 68 bytes as described in RFC 1950. 70 2.1. Registration Details 72 Type name: application 74 Subtype name: zlib 76 Required parameters: N/A 78 Optional parameters: N/A 80 Encoding considerations: needs base64 or other encoding that allows 81 arbitrary binary data 83 Security considerations: See section [security] below 85 Interoperability considerations: N/A 87 Published specification: [RFC1950] 89 Applications that use this media type: anywhere data size is an issue 91 Additional information: 93 Magic number(s): first byte is usually 0x78 but can also be 0x08, 94 0x18, 0x28, 0x38, 0x48, 0x58, or 0x68. 95 File extension(s): N/A 96 Macintosh file type code(s): N/A 98 Person and email address to contact for further information: see 99 http://zlib.net/ 101 Intended usage: COMMON 103 Restrictions on usage: N/A 105 Author: John Levine 107 Change controller: IETF 109 3. The Application/Gzip Media Type 111 The application/gzip media type describes a block of data that is 112 compressed using gzip [RFC1952] compression. The data is a stream of 113 bytes as described in RFC 1952. 115 3.1. Registration Details 117 Type name: application 119 Subtype name: gzip 121 Required parameters: N/A 123 Optional parameters: N/A 125 Encoding considerations: needs base64 or other encoding that allows 126 arbitrary binary data 128 Security considerations: See section [security] below 130 Interoperability considerations: N/A 132 Published specification: [RFC1952] 134 Applications that use this media type: anywhere data size is an issue 136 Additional information: 138 Magic number(s): first two bytes are 0x1f, 0x8b. 139 File extension(s): gz 140 Macintosh file type code(s): N/A 142 Person and email address to contact for further information: see 143 http://www.gzip.org/ 145 Intended usage: COMMON 147 Restrictions on usage: N/A 149 Author: John Levine 151 Change controller: IETF 153 4. Security Considerations 155 Zlib and gzip compression can be used to compress arbitrary binary 156 data such as hostile executable code. Also, data that purports to be 157 in zlib or gzip format may not be, and fields that are supposed to be 158 flags, lengths, or pointers, could contain anything. Applications 159 should treat any data with due skepticism. 161 Also see the security considerations in the underlying format 162 documents, Section 5 of [RFC1950], Section 6 of [RFC1951], and 163 Section 4 of [RFC1952]. 165 5. References 167 [RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data 168 Format Specification version 3.3", RFC 1950, May 1996. 170 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 171 version 1.3", RFC 1951, May 1996. 173 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L.P. and G. 174 Randers-Pehrson, "GZIP file format specification version 175 4.3", RFC 1952, May 1996. 177 Appendix A. Change log 179 Note to editor: Please remove this section before publication. 181 Appendix A.1. Changes from -01 to -02 183 Fix gzip.org 185 Note other former names 187 Appendix A.2. Changes from -00 to -01 189 Note former x-gzip 191 Refer to security sections in underlying format docs 193 Author's Address 195 John Levine 196 Taughannock Networks 197 PO Box 727 198 Trumansburg, NY 14886 200 Phone: +1 831 480 2300 201 Email: standards@taugh.com