multipart/related structure SHALL be satisfied by those resources and
not by resources from any another local or remote source.
Therefore, if a sender wishes a recipient to always retrieve an URI
referenced resource from its source, an URI labeled copy of that
resource MUST NOT be included in the same multipart/related
structure.
In addition, since the source of a resource received in a
multipart/related structure can be misrepresented (see 11.1 above),
if a resource received in multipart/related structure is stored in a
cache, it MUST NOT be retrieved from that cache other than by a
reference contained in a body part of the same multipart/related
structure. Failure to honor this directive will allow a
multipart/related structure to be employed as a Trojan Horse. For
example, to inject bogus resources (i.e. a misrepresentation of a
competitor's Web site) into a recipient's generally accessible Web
cache.
12. Differences as compared to the previous version of this proposed
standard in RFC2110
The specification has been changed to show that the formats described
do not only apply to multipart MIME in email, but also to multipart
MIME transferred through other protocols such as HTTP or FTP.
In order to agree with [RELURL], Content-Location headers in
multipart Content-Headings can now be used as a base to resolve
relative URIs in their component parts, but only if no base URI can
be derived from the component part itself. Base URIs in Content-
Location header fields in inner headings have precedence over base
URIs in outer multipart headings.
The Content-Base header, which was present in RFC2110, has been
removed. A conservative implementor may choose to accept this header
in input for compatibility with implementations of RFC2110, but MUST
never send any Content-Base header, since this header is not any more
a part of this standard.
A section 4.4.1 has been added, specifying how to handle the case of
sending a body part whose URI does not agree with the correct URI
syntax.
The handling of relative and absolute URIs for matching between body
parts have been merged into a single description, by specifying that
relative URIs, which cannot be resolved otherwise, should be handled
as if they had been given the URL "thismessage:/".
13. Acknowledgments
Harald T. Alvestrand, Richard Baker, Isaac Chan, Dave Crocker, Martin
J. Duerst, Lewis Geer, Roy Fielding, Ned Freed, Al Gilman, Paul
Hoffman, Andy Jacobs, Richard W. Jesmajian, Mark K. Joseph, Greg
Herlihy, Valdis Kletnieks, Daniel LaLiberte, Ed Levinson, Jay Levitt,
Albert Lunde, Larry Masinter, Keith Moore, Gavin Nicol, Martyn W.
Peck, Pete Resnick, Jon Smirl, Einar Stefferud, Jamie Zawinski, Steve
Zilles and several other people have helped us with preparing this
document. We alone take responsibility for any errors which may still
be in the document.
14. References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC2234, November 1997.
[CONDISP] Troost, R. and S. Dorner, "Communicating Presentation
Information in Internet Messages: The Content-
Disposition Header", RFC2183, August 1997.
[HOSTS] Braden, R., Ed., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC1123, October
1989.
[HTML-I18N] Yergeau, F., Nicol, G. Adams, G. and M. Duerst:
"Internationalization of the Hypertext Markup
Language", RFC2070, January 1997.
[HTML2] Berners-Lee, T. and D. Connolly: "Hypertext Markup
Language - 2.0", RFC1866, November 1995.
[HTML3.2] Dave Raggett: HTML 3.2 Reference Specification, W3C
Recommendation, January 1997, at URL
http://www.w3.org/TR/REC-html32.html
[HTTP] Berners-Lee, T., Fielding, R. and H. Frystyk,
"Hypertext Transfer Protocol -- HTTP/1.0", RFC1945,
May 1996.
[IETF-TERMS] Bradner, S., "Key words for use in RFCs to Indicate
Requirements Levels", BCP 14, RFC2119, March 1997.
[INFO] J. Palme: Sending HTML in MIME, an informational
supplement to the RFC: MIME Encapsulation of
Aggregate Documents, such as HTML (MHTML), Work in
Progress.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1321, April 1992.
[MIDCID] Levinson, E., "Content-ID and Message-ID Uniform
Resource Locators", RFC2387, August 1998.
[MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC2045, December 1996.
[MIME2] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types", RFC
2046, December 1996.
[MIME3] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions for
Non-ASCII Text", RFC2047, December 1996.
[MIME4] Freed, N., Klensin, J. and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four:
Registration Procedures", RFC2048, January 1997.
[MIME5] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Five: Conformance
Criteria and Examples", RFC2049, November 1996.
[NEWS] Horton, M. and R. Adams: "Standard for interchange of
USENET messages", RFC1036, December 1987.
[PDF] Tim Bienz and Richar Cohn: "Portable Document Format
Reference Manual", Addison-Wesley, Reading, MA, USA,
1993, ISBN 0-201-62628-4.
[REL] Levinson, E., "The MIME Multipart/Related Content-
Type", RFC2389, August 1998.
[RELURL] Fielding, R., "Relative Uniform Resource Locators",
RFC1808, June 1995.
[RFC822] Crocker, D., "Standard for the format of ARPA
Internet text messages." STD 11, RFC822, August
1982.
[SGML] ISO 8879. Information Processing -- Text and Office -
Standard Generalized Markup Language (SGML), 1986.
<URL:http://www.iso.ch/cate/d16387.html>
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC821, August 1982.
[URL] Berners-Lee, T., Masinter, L. and M. McCahill,
"Uniform Resource Locators (URL)", RFC1738, December
1994.
[URLBODY] Freed, N. and K. Moore, "Definition of the URL MIME
External-Body Access-Type", RFC2017, October 1996.
[VRML] Gavin Bell, Anthony Parisi, Mark Pesce: "Virtual
Reality Modeling Language (VRML) Version 1.0 Language
Specification." May 1995,
http://www.vrml.org/Specifications/.
[XML] Extensible Markup Language, published by the World
Wide Web Consortium, URL http://www.w3.org/XML/
15. Authors' Addresses
For contacting the editors, preferably write to Jacob Palme.
Jacob Palme
Stockholm University and KTH
Electrum 230
S-164 40 Kista, Sweden
Phone: +46-8-16 16 67
Fax: +46-8-783 08 29
EMail: jpalme@dsv.su.se
Alex Hopmann
Microsoft Corporation
One Microsoft Way
Redmond WA 98052
Phone: +1-425-703-8238
EMail: alexhop@microsoft.com
Nick Shelness
Lotus Development Corporation
55 Cambridge Parkway
Cambridge MA 02142-1295
EMail: Shelness@lotus.com
Working group chairman:
Einar Stefferud
EMail: stef@nma.com
16. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.