idnits 2.17.1 draft-levine-application-gzip-00.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 (February 2012) is 4454 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1951' is defined on line 156, but no explicit reference was found in the text == Unused Reference: 'RFC4288' is defined on line 163, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) Summary: 3 errors (**), 0 flaws (~~), 4 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 February 2012 5 Expires: August 14, 2012 7 The application/zlib and application/gzip media types 8 draft-levine-application-gzip-00 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 August 14, 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. They are used 52 to compress a wide variety of material, from unstructured text to 53 structured data to executable code. 55 2. The Application/Zlib Media Type 57 The application/zlib media type describes a block of data that is 58 compressed using Zlib [RFC1950] compression. The data is a stream of 59 bytes as described in RFC 1950. 61 2.1. Regsistration Details 63 Type name: application 65 Subtype name: zlib 67 Required parameters: none 69 Optional parameters: none 71 Encoding considerations: needs base64 or other encoding that allows 72 arbitrary binary data 74 Security considerations: See section [security] below 76 Interoperability considerations: none 78 Published specification: [RFC1950] 80 Applications that use this media type: anywhere data size is an issue 82 Additional information: 84 Magic number(s): first byte is usually 0x78 but can also be 0x08, 85 0x18, 0x28, 0x38, 0x48, 0x58, or 0x68. 86 File extension(s): none 87 Macintosh file type code(s): none 89 Person and email address to contact for further information: see 90 http://www.zlib.net/ 92 Intended usage: COMMON 94 Restrictions on usage: none 96 Author: John Levine 98 Change controller: IETF 100 3. The Application/Gzip Media Type 102 The application/gzip media type describes a block of data that is 103 compressed using gzip [RFC1952] compression. The data is a stream of 104 bytes as described in RFC 1952. 106 3.1. Regsistration Details 108 Type name: application 109 Subtype name: gzip 111 Required parameters: none 113 Optional parameters: none 115 Encoding considerations: needs base64 or other encoding that allows 116 arbitrary binary data 118 Security considerations: See section [security] below 120 Interoperability considerations: none 122 Published specification: [RFC1952] 124 Applications that use this media type: anywhere data size is an issue 126 Additional information: 128 Magic number(s): first two bytes are 0x1f, 0x8b. 129 File extension(s): gz 130 Macintosh file type code(s): none 132 Person and email address to contact for further information: see 133 http://www.gzip.net/ 135 Intended usage: COMMON 137 Restrictions on usage: none 139 Author: John Levine 141 Change controller: IETF 143 4. Security Considerations 145 Zlib and gzip compression can be used to compress arbitrary binary 146 data such as hostile executable code. Also, data that purports to be 147 in zlib or gzip format may not be, and fields that are supposed to be 148 flags, lengths, or pointers, could contain anything. Applications 149 should treat any data with due scepticism. 151 5. References 153 [RFC1950] Deutsch, L.P. and J-L. Gailly, "ZLIB Compressed Data 154 Format Specification version 3.3", RFC 1950, May 1996. 156 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 157 version 1.3", RFC 1951, May 1996. 159 [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L.P. and G. 160 Randers-Pehrson, "GZIP file format specification version 161 4.3", RFC 1952, May 1996. 163 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 164 Registration Procedures", BCP 13, RFC 4288, December 2005. 166 Author's Address 168 John Levine 169 Taughannock Networks 170 PO Box 727 171 Trumansburg, NY 14886 173 Phone: +1 831 480 2300 174 Email: standards@taugh.com