idnits 2.17.00 (12 Aug 2021) /tmp/idnits57218/draft-ietf-trade-mime-detector-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == 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 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 310 has weird spacing: '... (float indi...' -- 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 (November 2000) is 7850 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) ** Obsolete normative reference: RFC 2706 (ref. 'ECML') (Obsoleted by RFC 3106) ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 2801 (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) -- Possible downref: Non-RFC (?) normative reference: ref. 'W3C' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT MIME Handler Detection 2 Expires November 2000 4 HTTP MIME Type Handler Detection 5 ---- ---- ---- ------- --------- 6 8 Donald E. Eastlake 3rd 9 Chris J. Smith 10 David M. Soroka 12 Status of This Document 14 This draft is intended to become an Informational RFC. Distribution 15 of this document is unlimited. Comments should be sent to the TRADE 16 WG 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 RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 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 32 The list of Internet-Draft 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 some cases 41 they would want to display different web pages or content depending 42 on a MIME handler's availability. This document summarizes 43 reasonable techniques to solve this problem for most of the browsers 44 actually deployed on the Internet as of early 2000. 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 Acknowledegements 51 Helpful comments by Tony Lewis of Visa have been incorported. 53 Table of Contents 55 Status of This Document....................................1 56 Abstract...................................................1 58 Acknowledegements..........................................2 59 Table of Contents..........................................2 61 1. Introduction............................................3 62 2. The HTTP 'Accept' Header................................3 63 3. JavaScript..............................................3 64 4. ActiveX and the Windows Registry........................4 65 5. ECML, The Electronic Commerce Modeling Language.........5 66 6. Putting It All Together.................................5 67 7. Future Development......................................6 68 8. Security Considerations.................................6 69 9. IANA Considerations.....................................7 71 References.................................................8 73 Appendix A: Browser Version Sniffer Code...................9 75 Authors Addresses.........................................13 76 Expiration and File Name..................................13 78 1. Introduction 80 Entities composing web pages to provide services over [HTTP] 81 frequently have the problem of not knowing what [MIME] types have 82 handlers installed at a user's browser. For example, whether an 83 [IOTP] or VRML or [SET] or some streaming media handler is available. 84 In many cases they would want to display different web pages or 85 content depending on a MIME handler's availability. Sending a 86 response with a MIME type that is not supported frequently results in 87 interrupting the flow of the user experience, browser queries as to 88 what to do with the data being provided, and, of course, failure to 89 provide the behavior that would have occurred had the correct MIME 90 type handler been installed. 92 This document describes reasonable techniques to solve this problem 93 for most of the browsers actually deployed on the Internet as of 94 early 2000. It is intended to be of practical use to implementors 95 during the period before the wide deployment of superior standards 96 based techniques which may be developed. It is written in terms of 97 determining whether a handler for application/iotp or application/x- 98 iotp exists but is equally applicable to other MIME types. 100 2. The HTTP 'Accept' Header 102 The problem should be solved by the Hyper Text Transport Protocol 103 [HTTP] request "Accept" header which lists accepted [MIME] types. 104 This header is present in both Version 1.0 and 1.1 of HTTP and its 105 content is supposed to be a list of MIME types and subtypes that are 106 accepted. The only problem is that many browsers just send "*/*" or 107 the like. 109 If the particular MIME type you are looking for is specifically 110 present in the Accept header, it is generally safe to assume that a 111 handler for it is actually installed or part of the browser. 113 NOTE: Although not part of the main topic of this document, if you 114 are designing MIME type handler software and have access to a browser 115 interface that allows you to request the insertion of the MIME type 116 or types your software handles into the Accept header, you generally 117 should do so. It will make it easier for servers sensitive to that 118 MIME type to respond correctly. 120 3. JavaScript 122 Most recent browsers support one or more scripting languages of which 123 the most widely deployed is "JavaScript". These scripting languages 124 appear in web pages and permit the interpretive execution of 125 programing language constructs that can probe the browser 126 environment, conditionally cause different page contents to be 127 displayed, etc. For example, Appendix A shows JavaScript available 128 from the Netscape web site for determining what operating system, 129 browser, and version on which a web page is appearing. 131 NOTE: JavaScript is a trademark of SUN Microsystems, Inc. It was 132 originally called LiveScript. It has nothing to do with the Java 133 language. 135 The syntax for script use appears to be a Hyper Text Markup Language 136 (HTML) comment so that bowsers that do not support scripting will 137 ignore such items. That is, script use is preceeded by "". The following is a simple example of 139 conditional execution of parts of a web page based on JavaScript MIME 140 type handler detection. 142 156 4. ActiveX and the Windows Registry 158 If running on Microsoft Windows Internet Explorer version 3 or 4, it 159 is necessary to query the Windows Registry to determine local MIME 160 type support. Although these broswers support JavaScript, in v3 the 161 mimeTypes array is not present and in v4 the mimeTypes array is 162 present but always empty. For example, executing the following code 163 will test for support of the IOTP types: 165 CString iotpString, xiotpString; 166 char* Key, Keyx; 168 int rc, rcx; 169 iotpString = 170 "SOFTWARE\Classes\MIME\Database\Content Type\application/iotp"; 171 xiotpString = 172 "SOFTWARE\Classes\MIME\Database\Content Type\application/x-iotp"; 173 Key = iotpString.GetBuffer(1); 174 Keyx = xiotpString.GetBuffer(1); 175 rc = RegOpenKeyEx(HKEY_LOCAL_MACHINE, Key, 0, KEY_READ, hDefKey); 176 rcx = RegOpenKeyEx(HKEY_LOCAL_MACHINE, Key, 0, KEY_READ, hDefKey); 177 if ( ( rc == ERROR_SUCCESS ) || ( rcx == ERROR_SUCCESS ) ) 178 { 179 // IOTP Handler exists 180 } 181 else 182 { 183 // No IOTP Handler 184 } 186 NOTE: ActiveX is a trademark of Microsoft and was originally called 187 Sweeper. 189 5. ECML, The Electronic Commerce Modeling Language 191 A industry group has recently proposed a standard for fields used in 192 electronic commerce. This fields allow "wallet" software acting for 193 the consumer to convey standardized information to a merchant, 194 including information as to what payment related protocols are 195 supported at the customer site. See [ECML]. 197 6. Putting It All Together 199 The following diagram indicates how these techniques can be put 200 together. 202 start>-----+ 203 | 204 +------------------+ 205 | Was desired type | NO +-------------------------+ 206 |found in Accept? |------------>| Is JavaScript available | 207 +------------------+ |and does it show type? | 208 | +-------------------------+ 209 YES | | | | 210 |<---------------------------+ | NO | 211 | YES | | 212 | +---| 220 | V | 221 remember | Indeterminate. remember | 222 that |. Take default that type | 223 type IS | action. is NOT | 224 supported| supported | 225 X done X 227 7. Future Development 229 Active work is proceeding in the IETF, World Wide Web Consortium 230 [W3C], and other standards and industry groups concerning content and 231 capabilities negotiation. This work is likely to lead to superior 232 methods to implement the functionality described herein. However, 233 near universal deployment of such new standards/features will take 234 some time. Thus you should expect the methods given herein to be 235 obsoleted, but perhaps not for some time. 237 8. Security Considerations 239 It should be noted that the variety of ActiveX control suggested 240 above is reading the user's registry, that is, examining their 241 computer and reporting back some information it has discovered. This 242 may be a concern among some users. 244 In general, the use of JavaScript and, even more so, ActiveX is 245 dangerous because they are so powerful. JavaScript or ActiveX from a 246 web page could be invisibly damaging to the client. 248 Security of web interactions is normally provided by adopting channel 249 encryption on the browser to server connections, such as [TLS]. In 250 the absence of some such additional security outside of HTTP, 251 requests and/or responses may be forged or tampered with. 253 9. IANA Considerations 255 None specific to the techniques described herein. For MIME types and 256 type registration procedures, see [MIME: RFCs 2046, 2048]. 258 References 260 [ECML] 261 RFC 2706 - "ECML v1: Field Names for E-Commerce", D. Eastlake, 262 T. Goldstein, October 1999 264 [HTTP] RFC 1945 - "Hypertext Transfer Protocol -- HTTP/1.0", T. 265 Berners-Lee, R. Fielding & H. Frystyk. May 1996. 266 RFC 2616 - "Hypertext Transfer Protocol -- HTTP/1.1", R. 267 Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. 268 Berners-Lee. June 1999. 270 [IOTP] RFC 2801 - "Internet Open Trading Protocol - IOTP Version 271 1.0", D. Burett. April 2000. 273 [MIME] RFC 2045 - "Multipurpose Internet Mail Extensions (MIME) Part 274 One: Format of Internet Message Bodies", N. Freed & N. Borenstein. 275 November 1996. 276 RFC 2046 - "Multipurpose Internet Mail Extensions (MIME) Part 277 Two: Media Types", N. Freed & N. Borenstein. November 1996. 278 RFC 2047 - "MIME (Multipurpose Internet Mail Extensions) Part 279 Three: Message Header Extensions for Non-ASCII Text", K. Moore. 280 November 1996. 281 RFC 2048 - "Multipurpose Internet Mail Extensions (MIME) Part 282 Four: Registration Procedures", N. Freed, J. Klensin & J. Postel. 283 November 1996. 285 [SET] - "Secure Electronic Transaction (SET) Specification, Version 286 1.0", May 31, 1997, available from . 287 Book 1: Business Description 288 Book 2: Programmer's Guide 289 Book 3: Formal Protocol Definition 291 [TLS] RFC 2246 - "The TLS Protocol Version 1.0", T. Dierks, C. Allen. 293 [W3C] World Wide Web Consortium, 295 Appendix A: Browser Version Sniffer Code 297 488 Authors Addresses 490 Donald E. Eastlake 3rd 491 Motorola 492 65 Shindegan Hill Road 493 Carmel, NY 10512 USA 495 Telephone: +1 978-562-2827(h) 496 +1 508-261-5434(w) 497 FAX: +1 508-261-4447(w) 498 email: Donald.Eastlake@motorola.com 500 Chris J. Smith 501 Royal Bank of Canada 502 277 Front Street West 503 Toronto, Ontario M5V 3A4 CANADA 505 Telephone: +1 416-348-6090 506 FAX: +1 416-348-2210 507 email: chris.smith@royalbank.com 509 David M. Soroka 510 IBM 511 Raleigh, NC 513 Telephone: +1 919-486-2684 514 Fax: +1 919-543-4653 515 email: dsoroka@us.ibm.com 517 Expiration and File Name 519 This draft expires November 2000. 521 Its file name is draft-ietf-trade-mime-detector-03.txt.