752 Content-Location: CID: foo@bar.net
754 Note: Content-IDs MUST be globally unique [MIME1]. It is thus not
755 permitted to make them unique only within a message or within a single
756 multipart/related structure.
758 9. Examples
760 Warning: The examples are provided for illustrative purposes only. If
761 there is a contradiction between the explanatory text and the examples
762 in this standard, then the explanatory text is normative.
764 Notation: The examples contain indentation to show the structure, the
765 real objects should not be indented in this way.
767 9.1 Example of a HTML body without included linked objects
769 The first example is the simplest form of an HTML email message. This
770 message does not contain an aggregate HTML object, but simply a message
771 with a single HTML body part. This body part contains a URI but the
772 messages does not contain the resource referenced by that URI. To
773 retrieve the resource referenced by the URI the receiving client would
774 need either IP access to the Internet, or an electronic mail web
775 gateway.
777 From: foo1@bar.net
778 To: foo2@bar.net
779 Subject: A simple example
780 Mime-Version: 1.0
781 Content-Type: text/html; charset=iso-8859-1
782 Content-Transfer-Encoding: 8bit
784
785
786
787 Acute accent
788 The following two lines look have the same screen rendering:
789 E with acute accent becomes �.
790 E with acute accent becomes É.
791 Try clicking
792 here.
793
795 9.2 Example with an absolute URI to an embedded GIF picture
797 The second example is an HTML message which includes a single image,
798 referenced using the Content-Location mechanism.
800 From: foo1@bar.net
801 To: foo2@bar.net
802 Subject: A simple example
803 Mime-Version: 1.0
804 Content-Type: multipart/related; boundary="boundary-example";
805 type="text/html"; start=""
807 --boundary-example
808 Content-Type: text/html;charset=US-ASCII
809 Content-ID:
811 ... text of the HTML document, which might contain a URI
812 referencing a resource in another body part, for example
813 through a statement such as:
814
817 --boundary-example
818 Content-Location:
819 http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
820 Content-Type: IMAGE/GIF
821 Content-Transfer-Encoding: BASE64
823 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
824 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
825 etc...
827 --boundary-example--
829 9.3 Example with relative URIs to embedded GIF pictures
831 In this example, a Content-Location header field in the outermost
832 heading will be a base to all relative URLs, also inside the HTML text
833 being sent.
835 From: foo1@bar.net
836 To: foo2@bar.net
837 Subject: A simple example
838 Mime-Version: 1.0
839 Content-Location: http://www.ietf.cnri.reston.va.us/
840 Content-Type: multipart/related; boundary="boundary-example";
841 type="text/html"
843 --boundary-example
844 Content-Type: text/html; charset=ISO-8859-1
845 Content-Transfer-Encoding: QUOTED-PRINTABLE
847 ... text of the HTML document, which might contain URIs
848 referencing resources in other body parts, for example through
849 statements such as:
851
852
853
855 Example of a copyright sign encoded with Quoted-Printable: =A9
856 Example of a copyright sign mapped onto HTML markup: ¨
858 --boundary-example
859 Content-Location:
860 http://www.ietf.cnri.reston.va.us/images/ietflogo1.gif
861 ; Note - Absolute Content-Location does not require a
862 ; base
863 Content-Type: IMAGE/GIF
864 Content-Transfer-Encoding: BASE64
866 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
867 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
868 etc...
870 --boundary-example
871 Content-Location: ietflogo2.gif
872 ; Note - Relative Content-Location is resolved by base
873 ; specified in the Multipart/Related Content-Location heading
874 Content-Transfer-Encoding: BASE64
876 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
877 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
878 etc...
880 --boundary-example
881 Content-Location:
882 http://www.ietf.cnri.reston.va.us/images/ietflogo3.gif
883 Content-Transfer-Encoding: BASE64
885 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
886 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
887 etc...
889 --boundary-example--
891 9.4 Example with a relative URI and no BASE available
893 From: foo1@bar.net
894 To: foo2@bar.net
895 Subject: A simple example
896 Mime-Version: 1.0
897 Content-Type: multipart/related; boundary="boundary-example";
898 type="text/html"
900 --boundary-example
901 Content-Type: text/html; charset=iso-8859-1
902 Content-Transfer-Encoding: QUOTED-PRINTABLE
904 ... text of the HTML document, which might contain a URI
905 referencing a resource in another body part, for example
906 through a statement such as:
907
908 Example of a copyright sign encoded with Quoted-Printable: =A9
909 Example of a copyright sign mapped onto HTML markup: ¨
911 --boundary-example
912 Content-Location: ietflogo.gif
913 Content-Type: IMAGE/GIF
914 Content-Transfer-Encoding: BASE64
916 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
917 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
918 etc...
920 --boundary-example--
922 9.5 Example using CID URL and Content-ID header to an embedded GIF
923 picture
925 From: foo1@bar.net
926 To: foo2@bar.net
927 Subject: A simple example
928 Mime-Version: 1.0
929 Content-Type: multipart/related; boundary="boundary-example";
930 type="text/html"
932 --boundary-example
933 Content-Type: text/html; charset=US-ASCII
935 ... text of the HTML document, which might contain a URI
936 referencing a resource in another body part, for example
937 through a statement such as:
938
940 --boundary-example
941 Content-Location: CID:something@else ; this header is disregarded
942 Content-ID:
943 Content-Type: IMAGE/GIF
944 Content-Transfer-Encoding: BASE64
946 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
947 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
948 etc...
950 --boundary-example--
952 9.6 Example showing permitted and forbidden references between nested
953 body parts
955 This example shows in which cases references are allowed between
956 multiple multipart/related body parts in a message.
958 From: foo1@bar.net
959 To: foo2@bar.net
960 Subject: A simple example
961 Mime-Version: 1.0
962 Content-Type: multipart/related; boundary="boundary-example-1";
963 type="text/html"
965 --boundary-example-1
966 Content-Type: text/html;charset=US-ASCII
967 Content-ID:
969 The image reference below will be resolved with the image
970 in the next body part.
971
974 The image reference below cannot be resolved within this
975 MIME message, since it contains a reference from an outside
976 body part to an inside body part, which is not supported
977 by this standard.
978
981 The anchor reference immediately below will be resolved with
982 the nested text/html body part below:
983
989 Even more info
991 --boundary-example-1
992 Content-Location:
993 http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
994 Content-Type: IMAGE/GIF
995 Content-Transfer-Encoding: BASE64
997 R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
998 NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
999 etc...
1001 --boundary-example-1
1002 Content-Location:
1003 http://www.ietf.cnri.reston.va.us/more-info
1004 Content-Type: multipart/related; boundary="boundary-example-2";
1005 type="text/html"
1006 --boundary-example-2
1007 Content-Type: text/html;charset=US-ASCII
1008 Content-ID:
1010 The image reference below will be resolved with the image
1011 in the surrounding multipart/related above.
1012
1015 The image reference below will be resolved with the image
1016 inside the current nested multipart/related below.
1017
1020 --boundary-example-2
1021 Content-Location: http:images/ietflogo2e.gif
1022 Content-Type: IMAGE/GIF
1023 Content-Transfer-Encoding: BASE64
1025 R0lGODlhGAGgANX/ACkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nzc3t7e4
1026 SEhIyMjJSUlJycnKWlpa2trbW1tcDAwM7Ozv/eQnNzjHNzlGtrjGNjhFpae1pa
1027 etc...
1029 --boundary-example-2--
1030 --boundary-example-1
1031 Content-Location:
1032 http://www.ietf.cnri.reston.va.us/more-info
1033 Content-Type: multipart/related; boundary="boundary-example-3";
1034 type="text/html"
1035 --boundary-example-3
1036 Content-Type: text/html;charset=US-ASCII
1037 Content-ID: <4@foo@bar.net>
1039 The image reference below will be resolved with the image
1040 inside the current nested multipart/related below.
1041
1044 The image reference below cannot be resolved according to
1045 this standard since references between parallel multipart/
1046 related structures are not supported.
1047
1050 --boundary-example-3
1051 Content-Location: http:images/ietflogo2d.gif
1052 Content-Type: IMAGE/GIF
1053 Content-Transfer-Encoding: BASE64
1055 R0lGODlhGAGgANX/AMDAwCkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nz
1056 c3t7e4SEhIyMjJSUlJycnKWlpa2trbW1tb29vcbGxs7OztbW1t7e3ufn5+/v
1057 etc...
1059 --boundary-example-3--
1060 --boundary-example-1--
1062 10. Character encoding issues and end-of-line issues
1064 For the encoding of characters in HTML documents and other text
1065 documents into a MIME-compatible octet stream, the following mechanisms
1066 are relevant:
1068 - HTML [HTML2], [HTML-I18N] as an application of SGML [SGML] allows
1069 characters to be denoted by character entities as well as by numeric
1070 character references (e.g. "Latin small letter a with acute accent"
1071 may be represented by "á" or "á") in the HTML markup.
1073 - HTML documents, in common with other documents of the MIME
1074 Content-Type "text", can be represented in MIME using one of several
1075 character encodings. The MIME Content-Type "charset" parameter value
1076 indicates the particular encoding used. For the exact meaning and
1077 use of the "charset" parameter, please see [MIME2] chapter 4.
1079 Note that the "charset" parameter refers only to the MIME character
1080 encoding. For example, the string "á" can be sent in MIME
1081 with "charset=US-ASCII", while the raw character "Latin small letter
1082 a with acute accent" cannot.
1084 The above mechanisms are well defined and documented, and therefore not
1085 further explained here. In sending a message, all the above mentioned
1086 mechanisms MAY be used, and any mixture of them MAY occur when sending
1087 the document in MIME format. Receiving user agents (together with any
1088 Web browser they may use to display the document) MUST be capable of
1089 handling any combinations of these mechanisms.
1091 Also note that:
1093 - Any documents including HTML documents that contain octet values
1094 outside the 7-bit range need a content-transfer-encoding applied
1095 before transmission over certain transport protocols [MIME1,
1096 chapter 5].
1098 - The MIME standard [MIME2] requires that e-mailed documents of
1099 "Content-Type: Text/ MUST be in canonical form before a
1100 Content-Transfer-Encoding is applied, i.e. that line breaks are
1101 encoded as CRLFs, not as bare CRs or bare LFs or something else.
1102 This is in contrast to [HTTP] where section 3.6.1 allows other
1103 representations of line breaks.
1105 Note that this might cause problems with integrity checks based on
1106 checksums, which might not be preserved when moving a document from the
1107 HTTP to the MIME environment. If a document has to be converted in such
1108 a way that a checksum based message integrity check becomes invalid,
1109 then this integrity check header SHOULD be removed from the document.
1111 Other sources of problems are Content-Encoding used in HTTP but not
1112 allowed in MIME, and character sets that are not able to represent line
1113 breaks as CRLF. A good overview of the differences between HTTP and
1114 MIME with regards to Content-Type: "text" can be found in [HTTP],
1115 appendix C.
1117 Some transport mechanisms may specify a default "charset" parameter if
1118 none is supplied [HTTP, MIME1]. Because the default differs for
1119 different mechanisms, when HTML is transferred through e-mail, the
1120 charset parameter SHOULD be included, rather than relying on the
1121 default.
1123 11. Security Considerations
1125 11.1 Security considerations not related to caching
1127 It is possible for a message sender to misrepresent the source of a
1128 multipart/related body part to a message recipient by labeling it with
1129 a Content-Location URI that references another resource. Therefore,
1130 message recipients should only interpret Content-Location URIs as
1131 labeling a body part for the resolution of references from body parts
1132 in the same multipart/related message structure, and not as the source
1133 of a resource, unless this can be verified by other means.
1135 URIs, especially File URIs, if used without change in a message, may
1136 inadvertently reveal information that was not intended to be revealed
1137 outside a particular security context. Message senders should take care
1138 when constructing messages containing the new header fields, defined in
1139 this standard, that they are not revealing information outside of any
1140 security contexts to which they belong.
1142 Some resource servers hide passwords and tickets (access tokens to
1143 information which should not be reveled to others) and other sensitive
1144 information in non-visible fields or URIs within a text/html resource.
1145 If such a text/html resource is forwarded in an email message, this
1146 sensitive information may be inadvertently revealed to others.
1148 Since HTML documents can either directly contain executable content
1149 (i.e., JavaScript) or indirectly reference executable content (The
1150 "INSERT" specification, Java). It is exceedingly dangerous for a
1151 receiving User Agent to execute content received in a mail message
1152 without careful attention to restrictions on the capabilities of that
1153 executable content. (Why??? I do not understand this! What
1154 resdtrictions of what capabilities???/jp)
1156 HTML-formatted messages can be used to investigate user behaviour, for
1157 example to break anonymity, in ways which invade the privacy of
1158 individuals. If you send a message with a inline link to an object
1159 which is not itself included in the message, the recipients mailer or
1160 browser may request that object through HTTP. The HTTP transaction will
1161 then reveal who is reading the message. Example: A person who wants to
1162 find out who is behind an anonymous user identity, or from which
1163 workstation a user is reading his mail, can do this by sending a
1164 message with an inline link and then observe from where this link is
1165 used to request the object.
1167 11.2 Security considerations related to caching
1169 There is a well-known problem with the caching of directly retrieved
1170 web resources. A resource retrieved from a cache may differ from that
1171 re-retrieved from its source. This problem, also manifests itself when
1172 a copy of a resource is delivered in a multipart/related structure.
1174 When processing (rendering) a text/html body part in an MHTML
1175 multipart/related structure, all URIs in that text/html body part which
1176 reference subsidiary resources within the same multipart/related
1177 structure SHALL be satisfied by those resources and not by resources
1178 from any another local or remote source.
1180 Therefore, if a sender wishes a recipient to always retrieve an URI
1181 referenced resource from its source, an URI labeled copy of that
1182 resource MUST NOT be included in the same multipart/related structure.
1184 In addition, since the source of a resource received in a
1185 multipart/related structure can be misrepresented (see 11.1 above), if
1186 a resource received in multipart/related structure is stored in a
1187 cache, it MUST NOT be retrieved from that cache other than by a
1188 reference contained in a body part of the same multipart/related
1189 structure. Failure to honor this directive will allow a
1190 multipart/related structure to be employed as a Trojan Horse. For
1191 example, to inject bogus resources (i.e. a misrepresentation of a
1192 competitor's Web site) into a recipient's generally accessible Web
1193 cache.
1195 12. Differences as compared to the previous version of this proposed
1196 standard in RFC 2110
1198 The specification has been changed to show that the formats described
1199 do not only apply to multipart MIME in email, but also to multipart
1200 MIME transferred through other protocols such as HTTP or FTP.
1202 In order to agree with [RELURL], Content-Location headers in multipart
1203 Content-Headings can now be used as a base to resolve relative URIs in
1204 their component parts, but only if no base URI can be derived from the
1205 component part itself. Base URIs in Content-Location header fields in
1206 inner headings have precedence over base URIs in outer multipart
1207 headings.
1209 The Content-Base header, which was present in RFC 2110, has been
1210 removed. A conservative implementor may choose to accept this header in
1211 input for compatibility with implementations of RFC 2110, but MUST
1212 never send any Content-Base header, since this header is not any more a
1213 part of this standard.
1215 A section 4.4.1 has been added, specifying how to handle the case of
1216 sending a body part whose URI does not agree with the correct URI
1217 syntax.
1219 The handling of relative and absolute URIs for matching between body
1220 parts have been merged into a single description, by specifying that
1221 relative URIs, which cannot be resolved otherwise, should be handled as
1222 if they had been given the URL "this_message:/".
1224 13. Copyright
1226 Copyright (C) The Internet Society 1998. All Rights Reserved.
1228 This document and translations of it may be copied and furnished to
1229 others, and derivative works that comment on or otherwise explain it or
1230 assist in its implementation may be prepared, copied, published and
1231 distributed, in whole or in part, without restriction of any kind,
1232 provided that the above copyright notice and this paragraph are
1233 included on all such copies and derivative works. However, this
1234 document itself may not be modified in any way, such as by removing the
1235 copyright notice or references to the Internet Society or other
1236 Internet organizations, except as needed for the purpose of developing
1237 Internet standards in which case the procedures for copyrights defined
1238 in the Internet Standards process must be followed, or as required to
1239 translate it into languages other than English.
1241 The limited permissions granted above are perpetual and will not be
1242 revoked by the Internet Society or its successors or assigns.
1244 This document and the information contained herein is provided on an
1245 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1246 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
1247 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
1248 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
1249 FITNESS FOR A PARTICULAR PURPOSE.
1251 14. Acknowledgments
1253 Harald T. Alvestrand, Richard Baker, Isaac Chan, Dave Crocker, Martin
1254 J. Duerst, Lewis Geer, Roy Fielding, Ned Freed, Al Gilman, Paul
1255 Hoffman, Andy Jacobs, Richard W. Jesmajian, Mark K. Joseph, Greg
1256 Herlihy, Valdis Kletnieks, Daniel LaLiberte, Ed Levinson, Jay Levitt,
1257 Albert Lunde, Larry Masinter, Keith Moore, Gavin Nicol, Martyn W. Peck,
1258 Pete Resnick, Jon Smirl, Einar Stefferud, Jamie Zawinski, Steve Zilles
1259 and several other people have helped us with preparing this document. I
1260 alone take responsibility for any errors which may still be in the
1261 document.
1263 15. References
1265 Ref. Author, title
1266 --------- --------------------------------------------------------
1268 |ABNF] D. Rocker, P. Overell: Augmented BNF for Syntax
1269 Specifications: ABNF, RFC 2234, November 1997.
1271 [CONDISP] R. Troost, S. Dorner: "Communicating Presentation
1272 Information in Internet Messages: The
1273 Content-Disposition Header", RFC 2183, August 1997.
1275 [HOSTS] R. Braden (editor): "Requirements for Internet Hosts --
1276 Application and Support", STD-3, RFC 1123, October 1989.
1278 [HTML-I18N] F. Yergeau, G. Nicol, G. Adams, & M. Duerst:
1279 "Internationalization of the Hypertext Markup Language".
1280 RFC 2070, January 1997.
1282 [HTML2] T. Berners-Lee, D. Connolly: "Hypertext Markup Language
1283 - 2.0", RFC 1866, November 1995.
1285 [HTML3.2] Dave Raggett: HTML 3.2 Reference Specification, W3C
1286 Recommendation, January 1997, at URL
1287 http://www.w3.org/TR/REC-html32.html
1289 [HTTP] T. Berners-Lee, R. Fielding, H. Frystyk: Hypertext
1290 Transfer Protocol -- HTTP/1.0. RFC 1945, May 1996.
1292 [IETF-TERMS] S. Bradner: Key words for use in RFCs to Indicate
1293 Requirements Levels. RFC 2119, March 1997.
1295 [INFO] J. Palme: Sending HTML in MIME, an informational
1296 supplement to the RFC: MIME Encapsulation of Aggregate
1297 Documents, such as HTML (MHTML), work in progress within
1298 IETF in April 1998.
1300 [MD5] R. Rivest: "The MD5 Message-Digest Algorithm", RFC 1321,
1301 April 1992.
1303 [MIDCID] E. Levinson: Content-ID and Message-ID Uniform Resource
1304 Locators", draft-ietf-mhtml-cid-v2-00.txt, July 1997.
1306 [MIME1] N. Freed, N. Borenstein, "Multipurpose Internet Mail
1307 Extensions (MIME) Part One: Format of Internet Message
1308 Bodies", RFC 2045, December 1996.
1309 .
1310 [MIME2] N. Freed, N. Borenstein, "Multipurpose Internet Mail
1311 Extensions (MIME) Part Two: Media Types", RFC 2046,
1312 December 1996.
1314 [MIME3] K. Moore, "MIME (Multipurpose Internet Mail Extensions)
1315 Part Three: Message Header Extensions for Non-ASCII
1316 Text", RFC 2047, December 1996.
1318 [MIME4] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet
1319 Mail Extensions (MIME) Part Four: Registration
1320 Procedures", RFC 2048, January 1997.
1322 [MIME5] "Multipurpose Internet Mail Extensions (MIME) Part Five:
1323 Conformance Criteria and Examples", RFC 2049, December
1324 1996.
1326 [NEWS] M.R. Horton, R. Adams: "Standard for interchange of
1327 USENET messages", RFC 1036, December 1987.
1329 [PDF] Tim Bienz and Richar Cohn: "Portable Document Format
1330 Reference Manual", Addison-Wesley, Reading, MA, USA,
1331 1993, ISBN 0-201-62628-4.
1333 [REL] Edward Levinson: "The MIME
1334 Multipart/Related"multipart/related" Content-Type",
1335 draft-ietf-mhtml-re-v2-00.txt, September 1997.
1337 [RELURL] R. Fielding: "Relative Uniform Resource Locators", RFC
1338 1808, June 1995.
1340 [RFC822] D. Crocker: "Standard for the format of ARPA Internet
1341 text messages." STD 11, RFC 822, August 1982.
1343 [SGML] ISO 8879. Information Processing -- Text and Office -
1344 Standard Generalized Markup Language (SGML), 1986.
1345
1347 [SMTP] J. Postel: "Simple Mail Transfer Protocol", STD 10, RFC
1348 821, August 1982.
1350 [URL] T. Berners-Lee, L. Masinter, M. McCahill: "Uniform
1351 Resource Locators (URL)", RFC 1738, December 1994.
1353 [URLBODY] N. Freed and Keith Moore: "Definition of the URL MIME
1354 External-Body Access-Type", RFC 2017, October 1996.
1356 [VRML] Gavin Bell, Anthony Parisi, Mark Pesce: "Virtual Reality
1357 Modeling Language (VRML) Version 1.0 Language
1358 Specification." May 1995,
1359 http://www.vrml.org/Specifications/.
1361 [XML] Extensible Markup Language, published by the World Wide
1362 Web Consortium, URL http://www.w3.org/XML/
1364 16. Author's Addresses
1366 For contacting the editors, preferably write to Jacob Palme.
1368 Jacob Palme Phone: +46-8-16 16 67
1369 Stockholm University and KTH Fax: +46-8-783 08 29
1370 Electrum 230 Email: jpalme@dsv.su.se
1371 S-164 40 Kista, Sweden
1373 Alex Hopmann Email: alexhop@microsoft.com
1374 Microsoft Corporation Phone: +1-425-703-8238
1375 One Microsoft Way
1376 Redmond WA 98052
1378 Nick Shelness Email: Shelness@lotus.com
1379 Lotus Development Corporation
1380 55 Cambridge Parkway
1381 Cambridge MA 02142-1295
1383 Working group chairman:
1385 Einar Stefferud Email: stef@nma.com