idnits 2.17.1 draft-bahreman-mapplet-spec-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 current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 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. ** The abstract seems to contain references ([JAVA], [MIME]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 156: '...l parameter that MUST be specified in ...' RFC 2119 keyword, line 170: '...t, a Name parameter MUST appear in the...' RFC 2119 keyword, line 196: '... those sites. Applet designers SHOULD...' RFC 2119 keyword, line 252: '... Start parameter MUST specify the cont...' RFC 2119 keyword, line 254: '...ntity. The root MUST be of type Appli...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (13 December 1996) is 9995 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'JAVA' ** Obsolete normative reference: RFC 1521 (ref. 'MIME') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) -- Possible downref: Non-RFC (?) normative reference: ref. 'ENABLED-MAIL' ** Obsolete normative reference: RFC 1866 (ref. 'HTML') (Obsoleted by RFC 2854) -- Possible downref: Non-RFC (?) normative reference: ref. 'RELATED' -- Possible downref: Non-RFC (?) normative reference: ref. 'MHTML' ** Downref: Normative reference to an Historic RFC: RFC 1848 (ref. 'MOSS') Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT MIME Encapsulation of Aggregate Applet Objects (mapplet) 2 draft-bahreman-mapplet-spec-00.txt June 13 1996 3 Expires 13 December 1996 5 MIME Encapsulation of Aggregate Applet Objects (mapplet) 6 ---- ------------- -- --------- ------ ------- --------- 8 Alireza Bahreman 9 James Galvin 10 Rajkumar Narayanaswamy 11 Nick Zhang 13 INTERNET-DRAFT MIME Encapsulation of Aggregate Applet Objects (mapplet) 15 Status of This Document 17 This document is being circulated for comment. Please send your 18 comments to the authors at or to the mapplet 19 mail list . You can subscribe to the mailing list by 20 sending an email to majordomo@eit.com with the following line as the 21 only line in the BODY of the message: 23 subscribe mapplet your@email.address 25 To unsubscribe or find out more about using Majordomo, replace the BODY 26 with the line: 28 help 30 and send the message to majordomo@eit.com. If consensus is reached, 31 this document may be submitted to the IESG as a Proposed Standard 32 protocol specification for use with MIME. 34 This document is an Internet-Draft. Internet-Drafts are working 35 documents of the Internet Engineering Task Force (IETF), its areas, and 36 its working groups. Note that other groups may also distribute working 37 documents as Internet-Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months. 40 Internet-Drafts may be updated, replaced, or obsoleted by other 41 documents at any time. It is not appropriate to use Internet-Drafts as 42 reference material or to cite them other than as a ``working draft'' or 43 ``work in progress.'' 45 To learn the current status of any Internet-Draft, please check the 46 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 47 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 48 nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 49 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 51 Abstract 53 The applets written in the Java programming [JAVA] language are becoming 54 a household name on the World Wide Web. Currently, web browsers are 55 able to retrieve and display these applets. This document describes a 56 set of guidelines for conforming mail user agents to be able to send and 57 display applets. The applets are transferred within a MIME [MIME] 58 message. In order to do this, a new MIME subtype, Application/Applet, 59 is being defined in this document. We also discuss how other protocols 60 for adding security to MIME objects could be used to provide additional 61 security. 63 INTERNET-DRAFT MIME Encapsulation of Aggregate Applet Objects (mapplet) 65 Table of Contents 67 Status of This Document....................................2 68 Abstract...................................................2 69 Table of Contents..........................................3 71 1. Introduction............................................4 72 2. The MIME Application/Applet Content-Type................4 73 2.1 The Version Parameter..................................5 74 2.2 The Name Parameter.....................................5 75 2.3 The Site Parameter.....................................5 76 2.4 The Source Parameter...................................6 77 2.5 Syntax.................................................6 78 3. Sending a single applet.................................6 79 4. Use of the Content-Type: Multipart/Related..............6 80 5. Use in MIME encapsulation of aggregate HTML documents...7 81 6. Using MIME security to sign applets.....................8 82 7. Examples................................................8 83 7.1 Single self-contained applet...........................9 84 7.2 Aggregate applet with referred class...................9 85 7.3 Applet as data for MHTML..............................11 86 7.4 MOSS enhanced.........................................13 87 8. Encoding Considerations................................14 88 9. Security Considerations................................14 89 10. Application usage.....................................15 91 Acknowledgments...........................................16 92 Appendix A - IANA Registration Request....................16 93 References................................................16 94 Authors' Address..........................................17 95 Expiration and File Name..................................18 97 INTERNET-DRAFT MIME Encapsulation of Aggregate Applet Objects (mapplet) 99 1. Introduction 101 Currently, web browsers retrieve data and documents mostly in a "pull" 102 mode. That is, information is presented to the user upon accessing a 103 particular site. On the other hand, email is mostly used in a "push" 104 mode in which information is sent to the user, not necessarily involving 105 their initiative. The ability to extend the information access using 106 the push model expands the application and utility of the Information 107 Infrastructure. 109 In addition to static or "passive" data on the Net, it is desirable to 110 be able to retrieve and/or send "active" content. As an example of 111 active content, consider the applets written in Java, which are becoming 112 a household name on the World Wide Web. As a matter of fact, the idea 113 of interactive or active messaging has been proposed and experimented in 114 the email community for some time [ENABLED-MAIL]. 116 Combining the need for active content with the push model for 117 information delivery is exactly what is being advocated here. This 118 document describes a set of guidelines for confirming mail user agents 119 to be able to send and display applets. We describe how to encapsulate 120 an applet object in MIME. In order to do this, a new subtype, 121 Application/Applet, is being defined in this document. We also discuss 122 how other protocols for adding security to MIME objects could be used to 123 provide additional security. 125 An alternative approach is to simply send an email which includes the 126 pointer to an applet, and let the recipient retrieve the applet with 127 other means. That method is common practice on the Web today, where an 128 tag in an HTML [HTML] document is defined to be a pointer to 129 the applet. We do not further describe this alternative in this 130 document. 132 Section 2 of this document will describe the MIME subtype defined to 133 carry applet objects. Sections 3 through 5 discuss the relationship and 134 interactions with other existing MIME Content-Types. Using MIME 135 security techniques are outlined in Section 6. We include all examples 136 of MIME messages in Section 7. Sections 8 and 9 of the document 137 enumerate both the encoding and security considerations. An application 138 of this new MIME Content-Type is discussed in Section 10. Appendix A 139 provides a copy of the completed registration form being sent to IANA 140 for the registration of the Application/Applet Subtype. 142 2. The MIME Application/Applet Content-Type 144 We propose a new subtype of the Application Content-Type called, Applet, 145 to encapsulate information needed to transport an applet. The following 146 four parameters are also defined for the Content-Type field of 147 INTERNET-DRAFT MIME Encapsulation of Aggregate Applet Objects (mapplet) 149 Application/Applet. The first two parameters, Version and Name, are 150 mandatory. The other parameters, Site and Source, are optional. There 151 are numerous examples in Section 7 for the use of the Application/Applet 152 MIME Content-Type. 154 2.1 The Version Parameter 156 A critical parameter that MUST be specified in the Content-Type field 157 for Application/Applet is the version of the system the applet is 158 designed for. This is needed by the receiving end to determine the 159 system (e.g. interpreter) to invoke in order to process the applet. 160 This information is specified with a "version" parameter, as in: 162 Content-Type: application/applet; version="Java 1.0.2" 164 Unlike some other parameter values, the values of the version parameter 165 are NOT case sensitive. There is no default for this parameter. 167 2.2 The Name Parameter 169 In order to identify the class names for the applet and related classes 170 embedded in the Application/Applet, a Name parameter MUST appear in the 171 Content-Type field, as in: 173 Content-type: application/applet; name="MyApplet.class" 175 This will enable applets and related classes to be saved as their real 176 class file names before an applet interpreter is invoked to run the 177 applet. The values of the name parameter are case sensitive. 179 2.3 The Site Parameter 181 An optional parameter in the Content-Type field is the site (or sites) 182 to which the applet is to connect. This information is needed to be 183 conveyed to the application processing the applet which determines 184 whether or not to grant such privilege. (See Section 9 for additional 185 security considerations.) Since not all applets may require to connect 186 to other machines, this parameter is optional. The values of the site 187 parameter are NOT case sensitive. The default for this parameter is 188 null (i.e. no host). An example use of this parameter would be: 190 Content-Type: application/applet; 191 site="eco.eit.com:80, eco.eit.com:88" 193 INTERNET-DRAFT MIME Encapsulation of Aggregate Applet Objects (mapplet) 195 Note that the sheer presence of this parameter does NOT guarantee the 196 applet will be allowed to access those sites. Applet designers SHOULD 197 take this into consideration and design applets that detect this 198 situation and handle failure gracefully. 200 2.4 The Source Parameter 202 An optional parameter in the Content-Type field is the Source parameter. 203 This parameter indicates whether or not the message content is the 204 source code of the applet. The only case in-sensitive values of this 205 parameter are FALSE or TRUE. An example use of this parameter follows: 207 Content-Type: application/applet; source=TRUE 209 Default value for this parameter is FALSE. This means that the assumed 210 content of the message is the actual applet executables (encoded binary) 211 and not the source code. 213 2.5 Syntax 215 The formal grammar for the subtype Application/Applet Content-Type field 216 is specified by the following BNF: 218 <> 220 3. Sending a single applet 222 The simplest example of an applet object is one which needs no input 223 data and consists of only one file. In Java terminology, an applet 224 which refers only to the standard class libraries and consists of a 225 single class file. For example, the MyApplet.class file may contain an 226 applet which will display the message "Hello World", once started. This 227 applet can easily be encapsulated in a MIME message using the new 228 Content-Type. See Section 7.1 for an example of a single self-contained 229 applet encapsulated in MIME using the new Application/Applet Content- 230 Type. 232 4. Use of the Content-Type: Multipart/Related 234 For the more complicated applets, consider one with data input 235 parameters which refers to non standard classes. In this case, we need 236 to aggregate several components together. For this purpose, we suggest 237 INTERNET-DRAFT MIME Encapsulation of Aggregate Applet Objects (mapplet) 239 the use of the Multipart/Related MIME Content-Type [RELATED]. This 240 would allow the receiving mail user agent to process the components 241 together and in the appropriate order for display. See the example in 242 Section 7.2 for the use of the Multipart/Related Content-Type. 244 The value of the Type parameter or root of the Multipart/Related message 245 MUST be of type Application/Applet or Multipart/Alternative which CAN be 246 resolved to Application/Applet. (We suggest the use of 247 Multipart/Alternative to allow the sender to specify a readable text 248 description of the applet in addition to the applet itself; therefore if 249 the recipient fails to display the applet, it would be able to display 250 the text/plain description instead.) 252 The Start parameter MUST specify the content-ID of the compound object's 253 root. If not present, the "root" is the first body part in the 254 Multipart/Related entity. The root MUST be of type Application/Applet 255 or Multipart/Alternative which CAN be resolved to Application/Applet. 257 The Start-Info parameter can provide additional information such as the 258 data input parameters for the applet. The value of the Start-Info 259 parameter MUST be the content-ID of the message component that contains 260 the data for the applet. This may be a message of type Text/Html. 262 Similar to [MHTML], we also rely on an additional parameter, Includes, 263 in the Content-Type field of Multipart/Related. The case-insensitive 264 values of this parameter are COMPLETE and INCOMPLETE. They refer to 265 whether the aggregate MIME message includes all referred classes of the 266 applet object or not, respectively. The default value for the Includes 267 parameter is COMPLETE. 269 5. Use in MIME encapsulation of aggregate HTML documents 271 Since the applet can be considered a data object within an HTML object, 272 we envision a possible tight coupling between the MIME encapsulation of 273 aggregate HTML documents [MHTML] work and the work presented here. For 274 example, just like an image data would be included in a MIME 275 encapsulation of an HTML object with a tag, an applet data could 276 be included for an tag. 278 In order to do this, we recommend encapsulating the applet within a 279 Multipart/Related MIME object with no Start-Info. This is because the 280 HTML object would already convey the data input parameters for the 281 applet in the tag. See the example in Section 7.3 for a sample 282 MIME encapsulated HTML document containing an image and an applet. 284 INTERNET-DRAFT MIME Encapsulation of Aggregate Applet Objects (mapplet) 286 6. Using MIME security to sign applets 288 The MIME encapsulation of an applet object is vulnerable to the same 289 attacks as any other MIME object. In particular, it is possible for an 290 active eavesdropper to modify the MIME message in transit. Therefore, 291 neither the authenticity of the sender nor the integrity of the applet 292 can be relied upon. The content of the MIME message may be seen by any 293 passive eavesdropper. To combat these security concerns, the sender of 294 the MIME message could sign and optionally encrypt the MIME message 295 sent. The signature can be verified by the recipient (assuming the 296 public key of the sender is available) assuring the authenticity of the 297 sender and the integrity of the message contents. If encryption is 298 performed, the recipient can decrypt and be assured that no intermediary 299 was able to read the content of the message. Encryption provides for 300 confidentiality of the applet during transmit. 302 The framework within which security services may be applied to MIME body 303 parts is described in [RFC1847]. One can use Multipart/Signed and 304 Multipart/Encrypted Content-Types to secure MIME objects. Two 305 mechanisms for achieving security in MIME have been proposed 306 [MOSS][PGP/MIME], which use this framework. There is another protocol 307 specified [S/MIME] for adding cryptographic signature and/or encryption 308 services to MIME messages. The use of any one of these mechanisms is 309 suggested for providing additional security guarantees to the recipient 310 regarding the authenticity and confidentiality of the MIME encapsulated 311 applet object. 313 As an example, consider the use of the MOSS mechanism. To sign or 314 encrypt the applet, the applet class files are encapsulated in 315 Multipart/Related object which is in turn signed by MOSS and put into a 316 Multipart/Signed object. When the recipient gets the applet, they should 317 verify the MOSS signature first before invoking any application to run 318 the applet. If the signature verification fails, the recipient mail 319 user agent should prompt the user a warning dialog before proceeding to 320 the next step of invoking and/or executing the applet. Section 7.4 321 demonstrates a possible signed, MIME-encapsulated applet object using 322 the MOSS security extensions. 324 7. Examples 326 Here, we present example MIME messages for the various scenarios 327 outlined above. These examples are intended to clarify the usage. If 328 there is an inconsistency with the BNF syntax presented in Section 2.5, 329 the BNF syntax is the correct one. 331 INTERNET-DRAFT MIME Encapsulation of Aggregate Applet Objects (mapplet) 333 7.1 Single self-contained applet 335 This example demonstrates the use of the Application/Applet Content- 336 Type. The parameters specify the environment this applet runs in (Java 337 1.0.2), the original name it was saved under (MyApplet.class), and that 338 the body of this MIME message includes the executable and NOT the source 339 file for this applet (source=False). The body of the message then 340 contains the base64 encoded applet class file. 342 From: bahreman@eit.com 343 To: zhang@eit.com 344 Subject: The Hello World Applet 345 Content-Type: application/applet; 346 version="Java 1.0.2"; 347 name="MyApplet.class"; 348 source="False" 349 Content-Transfer-Encoding: base64 351 353 7.2 Aggregate applet with referred class 355 In this example, we are going to encapsulate an applet which has data 356 input and refers to another class. The Multipart/Related Content-Type 357 is used to aggregate all the parts together. The start and start-info 358 parameters of the Multipart/Related Content-Type indicate the unique 359 message id representing the part of the MIME message corresponding to 360 the main applet class file and its data input, respectively. The 361 include parameter specifies that all referred classes are included in 362 this message; obviously, non of the standard classes are included. The 363 message part corresponding to unique-id-one@foo.com is the main applet 364 class and specifies the request to connect to eco.eit.com:80 host using 365 the site parameter. (As mentioned before, the receiving system has the 366 right to grant or deny such access.) In addition to the executables and 367 the input data, this message contains the source code for the applet and 368 its referred class as indicated by the source=True parameter value in 369 the last two parts of this aggregate MIME object. 371 From: bahreman@eit.com 372 To: zhang@eit.com 373 Subject: A More Complicated Applet 374 Content-Type: multipart/related; boundary="boundary.1"; 375 type="application/applet"; 376 start="unique-id-one@foo.com"; 377 start-info="unique-id-two@foo.com"; 379 INTERNET-DRAFT MIME Encapsulation of Aggregate Applet Objects (mapplet) 381 includes="complete" 383 --boundary.1 384 Content-Type: text/html 385 Content-ID: "unique-id-two@foo.com" 387 388 389 390
391 392 393 394 395
396 397 399 --boundary.1 400 Content-Type: application/applet; 401 version="Java 1.0.2"; 402 name="MyApplet.class"; 403 site="eco.eit.com:80" 404 Content-ID: 405 Content-Transfer-Encoding: base64 407 409 --boundary.1 410 Content-Type: application/applet; 411 version="Java 1.0.2"; 412 name="ReferredClass.class" 413 Content-Transfer-Encoding: base64 415 417 --boundary.1 418 Content-Type: application/applet; 419 version="Java 1.0.2"; 420 name="MyApplet.java"; 421 source="True" 422 Content-Transfer-Encoding: 7Bit 424 <7Bit encoded source code for the applet class file> 426 --boundary.1 427 Content-Type: application/applet; 428 version="Java 1.0.2"; 429 name="ReferredClass.java"; 430 source="True" 432 INTERNET-DRAFT MIME Encapsulation of Aggregate Applet Objects (mapplet) 434 Content-Transfer-Encoding: 7Bit 436 <7Bit encoded source code for the referred class file> 438 --boundary.1 440 7.3 Applet as data for MHTML 442 This example demonstrates encapsulating an applet object within an 443 aggregate HTML document encapsulated in MIME. Basically, the applet 444 object and its related information (except the input data) are presented 445 as a Multipart/Related object. This object is then encapsulated inside 446 the Multipart/Related MIME message conveying the HTML document. In this 447 example, the HTML document is a relatively simple file which only points 448 to one applet and one image. Both the image data and the applet data are 449 therefore encapsulated in the outermost Multipart/Related Content-Type 450 for the aggregate HTML object. The applet aggregate object includes the 451 main class, its only referred class, and source code for both. No input 452 data for the applet is needed as that information (the tag) is 453 conveyed in the HTML document itself. 455 From: bahreman@eit.com 456 To: zhang@eit.com 457 Subject: A Complicated Applet Inside an HTML Document 458 Content-Base: "http://www.ietf.cnri.reston.va.us" 459 Content-Type: multipart/related; boundary="boundary.0"; 460 type="text/html" 462 --boundary.0 463 Content-Type: text/html 465 466 467 468
469 470 471 472 473
474 IETF Logo 475 476 478 --boundary.0 479 Content-Location: "/images/ietflogo.gif" 480 INTERNET-DRAFT MIME Encapsulation of Aggregate Applet Objects (mapplet) 482 Content-Type: image/gif; name="ietflogo.gif" 483 Content-Transfer-Encoding: base64 485 487 --boundary.0 488 Content-Type: multipart/related; boundary="boundary.1"; 489 type="application/applet"; 490 start="unique-id-one@foo.com" 492 --boundary.1 493 Content-Type: application/applet; 494 version="Java 1.0.2"; 495 name="MyApplet.class"; 496 site="eco.eit.com:80" 497 Content-ID: 498 Content-Transfer-Encoding: base64 500 502 --boundary.1 503 Content-Type: application/applet; 504 version="Java 1.0.2"; 505 name="ReferredClass.class" 506 Content-Transfer-Encoding: base64 508 510 --boundary.1 511 Content-Type: application/applet; 512 version="Java 1.0.2"; 513 name="MyApplet.java"; 514 source="True" 515 Content-Transfer-Encoding: 7Bit 517 <7Bit encoded source code for the applet class file> 519 --boundary.1 520 Content-Type: application/applet; 521 version="Java 1.0.2"; 522 name="ReferredClass.java"; 523 source="True" 524 Content-Transfer-Encoding: 7Bit 526 <7Bit encoded source code for the referred class file> 528 --boundary.1 530 --boundary.0 531 INTERNET-DRAFT MIME Encapsulation of Aggregate Applet Objects (mapplet) 533 7.4 MOSS enhanced 535 This example shows how to use MOSS [MOSS] to enhance the security of the 536 applet by signing it. This conforms to the security framework specified 537 by [RFC1847] for MIME messages. Other mechanisms such as that advocated 538 by [S/MIME] could also be used. In MOSS, the aggregate applet MIME 539 object is encapsulated by a message of type Multipart/Signed Content- 540 Type. The first part is the applet and the second part is the signature 541 for that object. 543 From: bahreman@eit.com 544 To: zhang@eit.com 545 Subject: Example of a Signed, Complicated Applet 546 Content-Type: multipart/signed; protocol="application/moss-signature"; 547 boundary="boundary.0" 549 --boundary.0 550 Content-Type: multipart/related; boundary="boundary.1"; 551 type="application/applet"; 552 start="unique-id-one@foo.com"; 553 start-info="unique-id-two@foo.com" 555 --boundary.1 556 Content-Type: text/html 557 Content-ID: "unique-id-two@foo.com" 559 560 561 562
563 564 565 566 567
568 569 571 --boundary.1 572 Content-Type: application/applet; 573 version="Java 1.0.2"; 574 name="MyApplet.class"; 575 site="eco.eit.com:80" 576 Content-ID: 577 Content-Transfer-Encoding: base64 579 581 --boundary.1 582 INTERNET-DRAFT MIME Encapsulation of Aggregate Applet Objects (mapplet) 584 Content-Type: application/applet; 585 version="Java 1.0.2"; 586 name="ReferredClass.class" 587 Content-Transfer-Encoding: base64 589 591 --boundary.1 593 --boundary.0 594 Content-Type: Application/Moss-signature 596 598 --boundary.0 600 8. Encoding Considerations 602 Base64 is recommended as the content transfer encoding mechanism for 603 applet and their referred classes embedded in an MIME message. For the 604 source code(s), the 7Bit encoding is recommended. The Multipart/Related 605 Content-Type should NOT be encoded. 607 9. Security Considerations 609 User beware that even a signed applet could be malicious! The security 610 enhancements suggested in this document will not protect the recipient 611 from an applet who's code is malicious. The only guarantee the signing 612 of a MIME encapsulated applet object provides is the authenticity of the 613 origin. The user must configure their mail user agents with extreme 614 caution in order to only run applets whose source is trusted. For 615 example, if the user trusts a company and regularly downloads 616 applications from their public servers and executes them, this user can 617 also receive signed applets from that company and execute them; the user 618 carries the same amount of risk in both cases. One might even argue 619 that we have increased the potential for abuse, by simply allowing the 620 sending of executables. 622 A key implementation guideline for temporary storage and execution of 623 the MIME encapsulated objects is to store the applet and referred class 624 files in a directory other than the local environment. Using Java 625 terminology, the Java applet and related classes should not be saved 626 into a directory which is specified in the CLASSPATH environment 627 variable. Collectively they should be saved into a temporary directory 628 for viewing. The reason for this is that some applet viewers or players 629 INTERNET-DRAFT MIME Encapsulation of Aggregate Applet Objects (mapplet) 631 treat all classes under CLASSPATH as local classes and therefore, some 632 security checks may be turned off. 634 Another security consideration to mention is the restrictions imposed on 635 the applet by the environment in which it is executed in. One of these 636 restrictions is to prevent the applet from opening a communication 637 channel to other sites. Recall that the Site parameter of the 638 Application/Applet Content-Type, if present, implies that the applet 639 requires communication to one or more sites. The policy of allowing or 640 denying this request MUST rest on the local environment. The host 641 addresses in the value of the Site parameter are informational and will 642 be used at the discretion of the confirming mail user agent and the 643 applet execution environment. 645 10. Application usage 647 <> 648 <> 649 <> 650 INTERNET-DRAFT MIME Encapsulation of Aggregate Applet Objects (mapplet) 652 Acknowledgments 654 The contributions of the following people to early drafts of this 655 document are greatly appreciated: 657 <> 659 Appendix A - IANA Registration Request 661 In order to register, this appendix captures the filled email template 662 for the registration of new values with IANA. This email message will 663 be sent to IANA. 665 To: IANA@isi.edu 667 Subject: Registration of new MIME content-type/subtype 669 MIME type name: Application 671 MIME subtype name: Applet 673 Required parameters: Version, Name 675 Optional parameters: Site, Source 677 Encoding considerations: base64 encoded content recommended for Applet 678 executables. For source, 7Bit is recommended. 680 Security considerations: In the pure MIME encapsulation of the 681 aggregate applet objects, no security is provided. The MIME objects 682 could be signed in conventional ways to provide a higher level of 683 security such as integrity and authenticity. However, users are 684 cautioned that none of these security measures ensures that the 685 executable applet is not malicious. 687 Published specification: draft-bahreman-mapplet-spec-00.txt 689 Person & email address to contact for further information: mapplet- 690 authors@eit.com 692 References 694 NOTE: This list contains some references to Internet drafts. It is 695 anticipated that these Internet Drafts will become RFC-s before this 696 memo. The references will then be changed to refer to the corresponding 697 INTERNET-DRAFT MIME Encapsulation of Aggregate Applet Objects (mapplet) 699 RFC instead. 701 [JAVA] James Gosling & Henry McGilton: "The Java(TM) Language 702 Environment: A White Paper", 703 http://www.javasoft.com/java.sun.com/whitePaper/java-whitepaper-1.html. 705 [MIME] N. Borenstein & N. Freed: "MIME (Multipurpose Internet Mail 706 Extensions) Part One: Mechanisms for Specifying and Describing the 707 Format of Internet Message Bodies", RFC 1521, September 1993. 709 [ENABLED-MAIL] N. Borenstein & M.T. Rose: "MIME Extensions for Mail- 710 Enabled Applications: application/Safe-Tcl and multipart/enabled-mail", 711 Draft in preparation, First Virtual Holdings, Dover Beach Consulting, 712 September 1993. 714 [HTML] T. Berners-Lee & D. Connolly: "Hypertext Markup Language - 2.0", 715 RFC 1866, November 1995. 717 [RELATED] Harald Tveit Alvestrand & Edward Levinson: "The Mime 718 Multipart/Related Content-Type", , May 719 1996. 721 [MHTML] Jacob Palme & Alexander Hopmann: "Mime E-mail Encapsulation of 722 Aggregate HTML Documents (MHTML)", , March 1996. 735 [S/MIME] RSA Data Security, ftp://ftp.rsa.com. 737 Authors' Address 739 Alireza Bahreman, Rajkumar Narayanaswamy, Nick Zhang 740 EIT/VeriFone 741 800 El Camino Real 742 Menlo Park, CA 94025 USA 744 Telephone: +1 415 617 8000 745 FAX: +1 415 617 8019 746 EMail: {bahreman, rajkumar, zhang}@eit.com 747 INTERNET-DRAFT MIME Encapsulation of Aggregate Applet Objects (mapplet) 749 mapplet-authors@eit.com 751 James Galvin 752 CommerceNet 753 4005 Miranda Ave., Suite 175 754 Palo Alto, CA 94304 756 Telephone: +1 415 858 1930x226 757 Fax: +1 415 858 1936 758 EMail: galvin@commerce.net 759 mapplet-authors@eit.com 761 Expiration and File Name 763 This draft expires 13 December 1996. 765 Its file name is draft-bahreman-mapplet-spec-00.txt.