idnits 2.17.1 draft-ietf-trade-mime-detector-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Bad filename characters: the document name given in the document, 'draft-ietf-trade-mime-detector-00.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-trade-mime-detector-00.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-trade-mime-detector-00.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-trade-mime-detector-00.txt,', but the file name used is 'draft-ietf-trade-mime-detector-00' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 16 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 282 has weird spacing: '... (float indi...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (November 1999) is 8928 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: 'RFC 2026' is mentioned on line 23, but not defined == Missing Reference: 'RFCs 2046' is mentioned on line 239, but not defined -- Looks like a reference, but probably isn't: '2048' on line 239 == Unused Reference: 'SET' is defined on line 263, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2068 (ref. 'HTTP') (Obsoleted by RFC 2616) -- No information found for draft-ietf-trade-iotp-v1 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IOTP' ** Obsolete normative reference: RFC 2048 (ref. 'MIME') (Obsoleted by RFC 4288, RFC 4289) -- Possible downref: Non-RFC (?) normative reference: ref. 'SET' ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 12 errors (**), 1 flaw (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT MIME Handler Detection 2 Expires November 1999 4 HTTP MIME Type Handler Detection 5 ---- ---- ---- ------- --------- 7 Donald E. Eastlake 3rd 8 Chris J. Smith 9 David M. Soroka 11 Status of This Document 13 This draft, file name draft-ietf-trade-mime-detector-00.txt, is 14 intended to become an Informational RFC. Distribution of this 15 document is unlimited. Comments should be sent to the TRADE WG 16 mailing list or to the authors. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of [RFC 2026]. Internet-Drafts are 20 working documents of the Internet Engineering Task Force (IETF), its 21 areas, and its working groups. Note that other groups may also 22 distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 32 Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 Entities composing web pages to provide services over HTTP frequently 38 have the problem of not knowing what MIME types have handlers 39 installed at a user's browser. For example, whether an IOTP or VRML 40 or SET or some streaming media handler is available. In many cases 41 they would want to display different web pages or content depending 42 on a MIME handler's availability. This document summarizes a 43 reasonable technique to solve this problem for most of the browsers 44 actually deployed on the Internet as of April 1999. It is intended 45 to be of practical use to implementors during the period before the 46 wide deployment of superior standards based techniques which may be 47 developed. 49 Table of Contents 51 Status of This Document....................................1 53 Abstract...................................................2 54 Table of Contents..........................................2 56 1. Introduction............................................3 57 2. The HTTP 'Accepts' Header...............................3 58 3. JavaScript..............................................3 59 4. Microsoft ActiveX and the Windows Registry..............4 60 5. Putting It All Together.................................5 61 6. Future Development......................................6 62 7. Security Considerations.................................6 63 8. IANA Considerations.....................................6 65 References.................................................7 67 Appendix A: Browser Version Sniffer Code...................8 69 Authors Addresses.........................................12 70 Expiration and File Name..................................12 72 1. Introduction 74 Entities composing web pages to provide services over [HTTP] 75 frequently have the problem of not knowing what [MIME] types have 76 handlers installed at a user's browser. For example, whether an 77 [IOTP] or VRML or SET or some streaming media handler is available. 78 In many cases they would want to display different web pages or 79 content depending on a MIME handler's availability. Sending a 80 response with a MIME type that is not supported frequently results in 81 interrupting the flow of the user experience, browser queries as to 82 what to do with the data being provided, and, of course, failure to 83 provide the behavior that would have occurred had the correct MIME 84 type handler been installed. 86 This document describes reasonable techniques to solve this problem 87 for most of the browsers actually deployed on the Internet as of 88 April 1999. It is intended to be of practical use to implementors 89 during the period before the wide deployment of superior standards 90 based techniques which may be developed. It is written in terms of 91 determining whether a handler for application/iotp or application/x- 92 iotp exists but is equally applicable to other MIME types. 94 2. The HTTP 'Accepts' Header 96 The problem should be solved by the Hyper Text Transport Protocol 97 [HTTP] request "Accepts" header which lists accepted [MIME] types. 98 This header is present in both Version 1.0 and 1.1 of HTTP and its 99 content is supposed to be a list of MIME types and subtypes that are 100 accepted. The only problem is that many browsers just send "*/*". 102 If the particular MIME type you are looking for is present in the 103 Accepts header, it is generally safe to assume that some specific 104 handler for it is actually installed or part of the browser. 106 NOTE: Although not part of the main topic of this document, if you 107 are designing MIME type handler software and have access to a browser 108 interface that allows you to request the insertion of the MIME type 109 or types your software handles into the Accepts header, you generally 110 should do so. It will make it easier for servers sensitive to that 111 MIME type to respond correctly. 113 3. JavaScript 115 Most recent browsers support one or more scripting languages of which 116 the most widely deployed is "JavaScript". These scripting languages 117 appear in web pages and permit the interpretive execution of 118 programing language constructs that can probe the browser 119 environment, conditionally cause different page contents to be 120 displayed, etc. For example, Appendix A shows JavaScript available 121 from the Netscape web site for determining what operating system, 122 browser, and version you are running on. 124 NOTE: JavaScript is a trademark of Netscape Corporation. It was 125 originally called LiveScript. It has nothing to do with Java. 127 The syntax for script use appears to be a Hyper Text Markup Language 128 (HTML) comment so that bowsers that do not support scripting will 129 ignore such items. That is, script use if preceeded by "". The following is a simple example of 131 conditional execution of parts of a web page based on JavaScript MIME 132 type handler detection. 134 148 4. Microsoft ActiveX and the Windows Registry 150 If running on Internet Explorer version 3 or 4, it is necessary to 151 query to Windows Registry to determine local MIME type support. 152 Although these broswers support JavaScript, in v3 the mimeTypes array 153 is not present and in v4 it is present but always empty. For 154 example, executing the following code will test for support of the 155 iotp types: 157 CString iotpString, xiotpString; 158 char* Key, Keyx; 160 int rc, rcx; 161 iotpString = 162 "SOFTWARE\Classes\MIME\Database\Content Type\application/iotp"; 163 xiotpString = 164 "SOFTWARE\Classes\MIME\Database\Content Type\application/x-iotp"; 165 Key = iotpString.GetBuffer(1); 166 Keyx = xiotpString.GetBuffer(1); 167 rc = RegOpenKeyEx(HKEY_LOCAL_MACHINE, Key, 0, KEY_READ, hDefKey); 168 rcx = RegOpenKeyEx(HKEY_LOCAL_MACHINE, Key, 0, KEY_READ, hDefKey); 169 if ( ( rc == ERROR_SUCCESS ) || ( rcx == ERROR_SUCCESS ) ) 170 { 171 // IOTP Handler exists 172 } 173 else 174 { 175 // No IOTP Handler 176 } 178 NOTE: Active X is a trademark of Microsoft and was originally called 179 Sweeper. 181 [TBD Stuff about ActiveX glue...?] 183 5. Putting It All Together 185 [..] 187 start>-----+ 188 | 189 +------------------+ 190 | Was desired type | NO +-------------------------+ 191 |found in Accepts? |------------>| Is JavaScript available | 192 +------------------+ |and does it show type? | 193 | +-------------------------+ 194 YES | | | | 195 |<---------------------------+ | NO | 196 | YES | | 197 | +---| 205 | V | 206 remember | Indeterminate remember | 207 that |. take default that type | 208 type IS | action. is NOT | 209 supported| supported | 210 X done X 212 [...] 214 6. Future Development 216 Active work is proceeding in the IETF and World Wide Web Consortium 217 concerning content and capabilities negotiation. This work is likely 218 to lead to superior methods to implement the functionality described 219 herein. However, near universal deployment of such new 220 standards/features will take some time. Thus you should expect the 221 methods given herein to be obsoleted, but perhaps not for a few 222 years. 224 7. Security Considerations 226 It should be noted that the type of Active X control suggested above 227 is reader the user's registry, that is, examining their computer and 228 reporting back some information it has discovered. This may be a 229 concern among some users. 231 Security of web interactions is normally provided by adopting channel 232 encryption on the browser to server connections, such as [TLS]. In 233 the absence of some such additional security outside of HTTP, 234 requests and/or responses may be forged or tampered with. 236 8. IANA Considerations 238 None specific to the techniques described herein. For MIME types and 239 type registration procedures, see [RFCs 2046, 2048]. 241 References 243 [HTTP] RFC 1945 - "Hypertext Transfer Protocol -- HTTP/1.0", T. 244 Berners-Lee, R. Fielding & H. Frystyk. May 1996. 245 RFC 2068 - "Hypertext Transfer Protocol -- HTTP/1.1", R. 246 Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee. January 247 1997. 249 [IOTP] draft-ietf-trade-iotp-v1.0-protocol-*.txt - David Burdett 251 [MIME] RFC 2045 - "Multipurpose Internet Mail Extensions (MIME) Part 252 One: Format of Internet Message Bodies", N. Freed & N. Borenstein. 253 November 1996. 254 RFC 2046 - "Multipurpose Internet Mail Extensions (MIME) Part 255 Two: Media Types", N. Freed & N. Borenstein. November 1996. 256 RFC 2047 - "MIME (Multipurpose Internet Mail Extensions) Part 257 Three: Message Header Extensions for Non-ASCII Text", K. Moore. 258 November 1996. 259 RFC 2048 - "Multipurpose Internet Mail Extensions (MIME) Part 260 Four: Registration Procedures", N. Freed, J. Klensin & J. Postel. 261 November 1996. 263 [SET] 265 [TLS] RFC 2246 - "The TLS Protocol Version 1.0", T. Dierks, C. Allen. 267 Appendix A: Browser Version Sniffer Code 269 431 Authors Addresses 433 Donald E. Eastlake 3rd 434 IBM 435 65 Shindegan Hill Road 436 Carmel, NY 10512 USA 438 Telephone: +1 914-276-2668(h) 439 +1 914-784-7913(w) 440 FAX: +1 914-784-3833(w) 441 email: dee3@us.ibm.com 443 Chris J. Smith 444 Royal Bank of Canada 445 277 Front Street West 446 Toronto, Ontario M5V 3A4 CANADA 448 Telephone: +1 416-348-6090 449 FAX: +1 416-348-2210 450 email: chris.smith@royalbank.com 452 David M. Soroka 453 IBM 454 Raleigh, NC 456 Telephone: +1 919-486-2684 457 Fax: +1 919-543-4653 458 email: dsoroka@us.ibm.com 460 Expiration and File Name 462 This draft expires November 1999. 464 Its file name is draft-ietf-trade-mime-detector-00.txt.