idnits 2.17.1 draft-babu-navmime-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 245. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 256. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 269. 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 1 longer page, the longest (page 1) being 281 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Typically clients announce "*/*" as "Accept" value. For this reason, NAV systems MUST not assume support for "multipart/proxy-response" when "*/*" or "multipart/*" is announced by clients in "Accept". An explicit announcement of "multipart/proxy-response" must only be considered. -- 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 (July 21, 2007) is 6123 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 56, but not defined == Unused Reference: 'RFC2616' is defined on line 185, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Babu Neelam 2 Internet-Draft Independent 3 Updates: RFC2616 July 21, 2007 4 (if approved) 5 Intended status: Standards Track 6 Expires: January 10, 2008 8 HTTP Performance extension for NAV systems 9 draft-babu-navmime-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 10, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 Typically an NAV (network-based anti-virus) system stores the 43 entire HTTP response from the server, scan the response for 44 malware and then transmits it to the client. This extension 45 attempts to better response time for Web traffic by letting the 46 NAV (network-based anti-virus) system save the time required for 47 the NAV system for transmission of data from the NAV system to 48 the client. In addition, this extension also helps in reporting 49 download progress and avoiding client connection timeout. 51 Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [RFC2119]. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Mechanism Overview . . . . . . . . . . . . . . . . . . . . . . 2 61 3. Definition of Multipart/proxy-response . . . . . . . . . . . . 3 62 4. Capability announcement by HTTP clients. . . . . . . . . . . . 3 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 64 6. Normative References . . . . . . . . . . . . . . . . . . . . . 3 65 Appendix A. Sample HTTP response received by a web client . . . . 4 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 Intellectual Property and Copyright Statements . . . . . . . . . . 5 69 1. Introduction 71 Network-based anti-virus systems (hereby referred to as NAV systems) 72 operate by 73 1. Re-assembling packets into files, 74 2. Scanning the file for any malware and 75 3. Transmitting the data. If any malware is not found, it sends an 76 error code to the client. Otherwise, it sends the data as-is to 77 the client. 79 This extension attempts to better response time for Web traffic by 80 letting the NAV system save the time required for the NAV system for 81 transmission of data from the NAV system to the client (step 3). 83 This extension allows an NAV system to send the packets to the Web 84 clients, while allowing them to re-assemble for it's scanning 85 purpose.The clients are expected to receive and store the packets, 86 but not process the received information. Once the scanning in the 87 NAV system is complete, it indicates the client whether to go ahead 88 and process the data already sent to the client or to ignore it 89 (because it contains some malware). By letting NAV system to send 90 the packets even before the scanning is complete, it is expected 91 that the time required to transmit the data from the NAV system to 92 the client is saved and hence increasing the response time. 94 In addition, this extension solves other issues. 95 - With NAV systems, it is possible that clients timeout while the 96 server is scanning the data. As this extension allows the proxy 97 to send the data while scanning is still in progress, this is 98 not an issue anymore 99 - With NAV systems, clients fail to report the progress of 100 download as it doesn't receive the data till scanning is 101 complete in proxy. As this extension allows the proxy to send 102 the data while scanning is still in progress, this is not an 103 issue anymore 105 2. Mechanism Overview 107 This extension defines 108 - A new subtype for multipart MIME type & describes the desirable 109 support required for this subtype in web clients, servers, NAV 110 systems. 111 - A way for web clients to announce their support for this 112 extension: using Accept request header field. 114 3. Definition of Multipart/proxy-response 116 (1) MIME type name: multipart 117 (2) MIME subtype name: proxy-response 118 (3) Required parameters: none 119 (4) Optional parameters: none 121 NAV systems supporting this extension MAY send a message body 122 containing multipart/proxy-response. When multipart/proxy-response 123 is sent, no other MIME types are expected in the HTTP response. 125 The multipart/proxy-response content type contains either two or 126 three sub-parts, in the following order: 127 - The first body part is the HTTP response (including response 128 line, headers) received by proxy from the server. 129 - The second body part is labeled as text/plain. This body must 130 indicate whether server's HTTP response should be processed or 131 ignored. The body for this sub-part should be: 132 Proxy result PROCEED 133 OR 134 Proxy result IGNORE 135 - This sub-part is required only if the second body part contains 136 "Proxy result IGNORE". This body part provides HTTP response 137 that needs to be displayed to the user. 139 As the NAV system starts receiving the response from HTTP server, it 140 should store the data into a file for its scanning as well as start 141 sending the first sub-part to the client as described above. Once the 142 NAV system receives the HTTP response completely, it should scan the 143 stored file and then should send the second sub-part and third 144 sub-part (if necessary) to the client. 146 For some reason, if a client doesn't receive second and third (when 147 applicable) sub-parts, it should never store/process the already 148 received data. 150 4. Capability announcement by HTTP clients 152 Clients capable of processing multipart/proxy-response should send 153 "multipart/proxy-response" as one of the one of the media type. 155 Typically clients announce "*/*" as "Accept" value. For this reason, 156 NAV systems MUST not assume support for "multipart/proxy-response" 157 when "*/*" or "multipart/*" is announced by clients in "Accept". An 158 explicit announcement of "multipart/proxy-response" must only be 159 considered. 161 5. IANA Considerations 163 This document (if approved) requests IANA to allocate 164 "proxy-response" sub type for "multipart" MIME type. 166 Note to RFC Editor: this section may be removed on publication as an 167 RFC. 169 6. Security Considerations 171 Some programs like browsers' "Download Manager" start storing the 172 data to disk even before the complete response is received. Such 173 applications should ensure that they delete any partial data in the 174 event of "Proxy response IGNORE" or when second/third body (when 175 applicable) parts are not received. At times, it is possible that a 176 workstation auto-restarts/crashes after starting to receive the HTTP 177 response and before secind and/or third sub-parts. For this reason, 178 such programs are expected to save data only to some temporary 179 directory. After the download is complete, they are are expected to 180 be moved to the path requested by the user. After a system restart, 181 client should ensure that they clean up this temporary directory. 183 7. Normative References 185 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 186 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 187 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 189 Appendix A. Sample HTTP response received by a web client 191 HTTP/1.1 200 OK 192 Content-Type: multipart/proxy-response 193 HTTP/1.1 200 OK 194 Date: Fri, 31 Dec 1999 23:59:59 GMT 195 Content-Type: text/html 196 Content-Length: 1354 198 199 200

Happy New Millennium!

201 (more file contents) 202 . 203 . 204 . 205 206 208 Content-type:text/plain 209 Content-length: 210 Proxy result IGNORE 212 Content-type: text/plain 213 Content-length: 214 The requested URL contains malware 216 Author's Address 218 Babu Neelam 219 Intoto Software India Private Ltd. 220 8-3-1111/2, kesava nagar colony, 221 sriniagar colony main road, 222 punjagutta, 223 Hyderabad, 224 India. 226 Email: babun@intoto.com 228 Comments are solicited and should be addressed to the working 229 group's mailing list at ietf-http-wg@w3.org and/or the author(s). 231 Full Copyright Statement 233 Copyright (C) The IETF Trust (2007). 235 This document is subject to the rights, licenses and restrictions 236 contained in BCP 78, and except as set forth therein, the authors 237 retain all their rights. 239 This document and the information contained herein are provided on an 240 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 241 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 242 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 243 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 244 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 245 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 247 Intellectual Property 249 The IETF takes no position regarding the validity or scope of any 250 Intellectual Property Rights or other rights that might be claimed to 251 pertain to the implementation or use of the technology described in 252 this document or the extent to which any license under such rights 253 might or might not be available; nor does it represent that it has 254 made any independent effort to identify any such rights. Information 255 on the procedures with respect to rights in RFC documents can be 256 found in BCP 78 and BCP 79. 258 Copies of IPR disclosures made to the IETF Secretariat and any 259 assurances of licenses to be made available, or the result of an 260 attempt made to obtain a general license or permission for the use of 261 such proprietary rights by implementers or users of this 262 specification can be obtained from the IETF on-line IPR repository at 263 http://www.ietf.org/ipr. 265 The IETF invites any interested party to bring to its attention any 266 copyrights, patents or patent applications, or other proprietary 267 rights that may cover technology that may be required to implement 268 this standard. Please address the information to the IETF at 269 ietf-ipr@ietf.org. 271 Acknowledgment 273 Funding for the RFC Editor function is provided by the IETF 274 Administrative Support Activity (IASA).