draft-ietf-httpbis-content-disp-08.txt   draft-ietf-httpbis-content-disp-09.txt 
HTTPbis Working Group J. Reschke HTTPbis Working Group J. Reschke
Internet-Draft greenbytes Internet-Draft greenbytes
Updates: 2616 (if approved) March 14, 2011 Updates: 2616 (if approved) March 28, 2011
Intended status: Standards Track Intended status: Standards Track
Expires: September 15, 2011 Expires: September 29, 2011
Use of the Content-Disposition Header Field in the Use of the Content-Disposition Header Field in the
Hypertext Transfer Protocol (HTTP) Hypertext Transfer Protocol (HTTP)
draft-ietf-httpbis-content-disp-08 draft-ietf-httpbis-content-disp-09
Abstract Abstract
RFC 2616 defines the Content-Disposition response header field, but RFC 2616 defines the Content-Disposition response header field, but
points out that it is not part of the HTTP/1.1 Standard. This points out that it is not part of the HTTP/1.1 Standard. This
specification takes over the definition and registration of Content- specification takes over the definition and registration of Content-
Disposition, as used in HTTP, and clarifies internationalization Disposition, as used in HTTP, and clarifies internationalization
aspects. aspects.
Editorial Note (To be removed by RFC Editor before publication) Editorial Note (To be removed by RFC Editor before publication)
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Disposition in the HTTP/1.1 specification, as currently revised by Disposition in the HTTP/1.1 specification, as currently revised by
the IETF HTTPbis working group. See also the IETF HTTPbis working group. See also
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/123>. <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/123>.
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://trac.tools.ietf.org/wg/httpbis/trac/ at <http://trac.tools.ietf.org/wg/httpbis/trac/
query?component=content-disp> and related documents (including fancy query?component=content-disp> and related documents (including fancy
diffs) can be found at <http://tools.ietf.org/wg/httpbis/>. diffs) can be found at <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix E.12. The changes in this draft are summarized in Appendix E.13.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 15, 2011. This Internet-Draft will expire on September 29, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 26 skipping to change at page 3, line 26
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Internationalization Considerations . . . . . . . . . . . . . 8 6. Internationalization Considerations . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. Registry for Disposition Values and Parameter . . . . . . 9 8.1. Registry for Disposition Values and Parameter . . . . . . 9
8.2. Header Field Registration . . . . . . . . . . . . . . . . 9 8.2. Header Field Registration . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Changes from the RFC 2616 Definition . . . . . . . . 10 Appendix A. Changes from the RFC 2616 Definition . . . . . . . . 11
Appendix B. Differences compared to RFC 2183 . . . . . . . . . . 11 Appendix B. Differences compared to RFC 2183 . . . . . . . . . . 11
Appendix C. Alternative Approaches to Internationalization . . . 11 Appendix C. Alternative Approaches to Internationalization . . . 11
C.1. RFC 2047 Encoding . . . . . . . . . . . . . . . . . . . . 11 C.1. RFC 2047 Encoding . . . . . . . . . . . . . . . . . . . . 12
C.2. Percent Encoding . . . . . . . . . . . . . . . . . . . . . 12 C.2. Percent Encoding . . . . . . . . . . . . . . . . . . . . . 12
C.3. Encoding Sniffing . . . . . . . . . . . . . . . . . . . . 12 C.3. Encoding Sniffing . . . . . . . . . . . . . . . . . . . . 12
C.4. Implementations (to be removed by RFC Editor before C.4. Implementations (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . . . . 12 publication) . . . . . . . . . . . . . . . . . . . . . . . 12
Appendix D. Advice on Generating Content-Disposition Header Appendix D. Advice on Generating Content-Disposition Header
Fields . . . . . . . . . . . . . . . . . . . . . . . 13 Fields . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix E. Change Log (to be removed by RFC Editor before Appendix E. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 14 publication) . . . . . . . . . . . . . . . . . . . . 14
E.1. Since draft-reschke-rfc2183-in-http-00 . . . . . . . . . . 14 E.1. Since draft-reschke-rfc2183-in-http-00 . . . . . . . . . . 14
E.2. Since draft-reschke-rfc2183-in-http-01 . . . . . . . . . . 14 E.2. Since draft-reschke-rfc2183-in-http-01 . . . . . . . . . . 14
E.3. Since draft-reschke-rfc2183-in-http-02 . . . . . . . . . . 14 E.3. Since draft-reschke-rfc2183-in-http-02 . . . . . . . . . . 15
E.4. Since draft-reschke-rfc2183-in-http-03 . . . . . . . . . . 15 E.4. Since draft-reschke-rfc2183-in-http-03 . . . . . . . . . . 15
E.5. Since draft-ietf-httpbis-content-disp-00 . . . . . . . . . 15 E.5. Since draft-ietf-httpbis-content-disp-00 . . . . . . . . . 15
E.6. Since draft-ietf-httpbis-content-disp-01 . . . . . . . . . 15 E.6. Since draft-ietf-httpbis-content-disp-01 . . . . . . . . . 15
E.7. Since draft-ietf-httpbis-content-disp-02 . . . . . . . . . 15 E.7. Since draft-ietf-httpbis-content-disp-02 . . . . . . . . . 15
E.8. Since draft-ietf-httpbis-content-disp-03 . . . . . . . . . 15 E.8. Since draft-ietf-httpbis-content-disp-03 . . . . . . . . . 15
E.9. Since draft-ietf-httpbis-content-disp-04 . . . . . . . . . 16 E.9. Since draft-ietf-httpbis-content-disp-04 . . . . . . . . . 16
E.10. Since draft-ietf-httpbis-content-disp-05 . . . . . . . . . 16 E.10. Since draft-ietf-httpbis-content-disp-05 . . . . . . . . . 16
E.11. Since draft-ietf-httpbis-content-disp-06 . . . . . . . . . 16 E.11. Since draft-ietf-httpbis-content-disp-06 . . . . . . . . . 16
E.12. Since draft-ietf-httpbis-content-disp-07 . . . . . . . . . 17 E.12. Since draft-ietf-httpbis-content-disp-07 . . . . . . . . . 17
E.13. Since draft-ietf-httpbis-content-disp-08 . . . . . . . . . 17
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
RFC 2616 defines the Content-Disposition response header field in RFC 2616 defines the Content-Disposition response header field in
Section 19.5.1 of [RFC2616], but points out that it is not part of Section 19.5.1 of [RFC2616], but points out that it is not part of
the HTTP/1.1 Standard (Section 15.5): the HTTP/1.1 Standard (Section 15.5):
Content-Disposition is not part of the HTTP standard, but since it Content-Disposition is not part of the HTTP standard, but since it
is widely implemented, we are documenting its use and risks for is widely implemented, we are documenting its use and risks for
skipping to change at page 4, line 32 skipping to change at page 4, line 32
Note: this document does not apply to Content-Disposition header Note: this document does not apply to Content-Disposition header
fields appearing in payload bodies transmitted over HTTP, such as fields appearing in payload bodies transmitted over HTTP, such as
when using the media type "multipart/form-data" ([RFC2388]). when using the media type "multipart/form-data" ([RFC2388]).
2. Notational Conventions 2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This specification uses the augmented BNF notation defined in Section This specification uses the augmented BNF (ABNF) notation defined in
2.1 of [RFC2616], including its rules for implied linear whitespace Section 2.1 of [RFC2616], including its rules for implied linear
(LWS). whitespace (LWS).
3. Conformance and Error Handling 3. Conformance and Error Handling
This specification defines conformance criteria for both senders This specification defines conformance criteria for both senders
(usually, HTTP origin servers) and recipients (usually, HTTP user (usually, HTTP origin servers) and recipients (usually, HTTP user
agents) of the Content-Disposition header field. An implementation agents) of the Content-Disposition header field. An implementation
is considered conformant if it complies with all of the requirements is considered conformant if it complies with all of the requirements
associated with its role. associated with its role.
This specification also defines certain forms of the header field- This specification also defines certain forms of the header field-
skipping to change at page 5, line 45 skipping to change at page 5, line 45
token = <token, defined in [RFC2616], Section 2.2> token = <token, defined in [RFC2616], Section 2.2>
quoted-string = <quoted-string, defined in [RFC2616], Section 2.2> quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>
value = <value, defined in [RFC2616], Section 3.6> value = <value, defined in [RFC2616], Section 3.6>
; token | quoted-string ; token | quoted-string
Defined in [RFC5987]: Defined in [RFC5987]:
ext-value = <ext-value, defined in [RFC5987], Section 3.2> ext-value = <ext-value, defined in [RFC5987], Section 3.2>
Header field values with multiple instances of the same parameter Content-Disposition header field values with multiple instances of
name are invalid. the same parameter name are invalid.
Note that due to the rules for implied linear whitespace (Section 2.1 Note that due to the rules for implied linear whitespace (Section 2.1
of [RFC2616]), OPTIONAL whitespace can appear between words (token or of [RFC2616]), OPTIONAL whitespace can appear between words (token or
quoted-string) and separator characters. quoted-string) and separator characters.
Furthermore note that the format used for ext-value allows specifying Furthermore note that the format used for ext-value allows specifying
a natural language; this is of limited use for filenames and is a natural language (e.g., "en"); this is of limited use for filenames
likely to be ignored by recipients. and is likely to be ignored by recipients.
4.2. Disposition Type 4.2. Disposition Type
If the disposition type matches "attachment" (case-insensitively), If the disposition type matches "attachment" (case-insensitively),
this indicates that the recipient should prompt the user to save the this indicates that the recipient should prompt the user to save the
response locally, rather than process it normally (as per its media response locally, rather than process it normally (as per its media
type). type).
On the other hand, if it matches "inline" (case-insensitively), this On the other hand, if it matches "inline" (case-insensitively), this
implies default processing. Therefore, the disposition type "inline" implies default processing. Therefore, the disposition type "inline"
skipping to change at page 7, line 20 skipping to change at page 7, line 20
achieve this is to never trust folder name information in the achieve this is to never trust folder name information in the
filename parameter, for instance by stripping all but the last filename parameter, for instance by stripping all but the last
path segment and only consider the actual filename (where 'path path segment and only consider the actual filename (where 'path
segment' are the components of the field value delimited by the segment' are the components of the field value delimited by the
path separator characters "\" and "/"). path separator characters "\" and "/").
o Many platforms do not use Internet Media Types ([RFC2046]) to hold o Many platforms do not use Internet Media Types ([RFC2046]) to hold
type information in the file system, but rely on filename type information in the file system, but rely on filename
extensions instead. Trusting the server-provided file extension extensions instead. Trusting the server-provided file extension
could introduce a privilege escalation when the saved file is could introduce a privilege escalation when the saved file is
later opened (consider ".exe"). Thus, recipients SHOULD ensure later opened (consider ".exe"). Thus, recipients which make use
that a file extension is used that is safe, optimally matching the of file extensions to determine the media type MUST ensure that a
media type of the received payload. file extension is used that is safe, optimally matching the media
type of the received payload.
o Recipients SHOULD strip or replace character sequences that are o Recipients SHOULD strip or replace character sequences that are
known to cause confusion both in user interfaces and in filenames, known to cause confusion both in user interfaces and in filenames,
such as control characters and leading and trailing whitespace. such as control characters and leading and trailing whitespace.
o Other aspects recipients need to be aware of are names that have a o Other aspects recipients need to be aware of are names that have a
special meaning in the file system or in shell commands, such as special meaning in the file system or in shell commands, such as
"." and "..", "~", "|", and also device names. Recipients SHOULD "." and "..", "~", "|", and also device names. Recipients SHOULD
ignore or substitute names like these. ignore or substitute names like these.
skipping to change at page 9, line 38 skipping to change at page 9, line 38
Header field name: Content-Disposition Header field name: Content-Disposition
Applicable protocol: http Applicable protocol: http
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document: this specification (Section 4) Specification document: this specification (Section 4)
Related information: none
9. Acknowledgements 9. Acknowledgements
Thanks to Adam Barth, Rolf Eike Beer, Stewart Bryant, Bjoern Thanks to Adam Barth, Rolf Eike Beer, Stewart Bryant, Bjoern
Hoehrmann, Alfred Hoenes, Roar Lauritzsen, Alexey Melnikov, Henrik Hoehrmann, Alfred Hoenes, Roar Lauritzsen, Alexey Melnikov, Henrik
Nordstrom, and Mark Nottingham for their valuable feedback. Nordstrom, and Mark Nottingham for their valuable feedback.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 10, line 46 skipping to change at page 10, line 48
form-data", RFC 2388, August 1998. form-data", RFC 2388, August 1998.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, Procedures for Message Header Fields", BCP 90,
RFC 3864, September 2004. RFC 3864, September 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax", "Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005. STD 66, RFC 3986, January 2005.
[US-ASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
Appendix A. Changes from the RFC 2616 Definition Appendix A. Changes from the RFC 2616 Definition
Compared to Section 19.5.1 of [RFC2616], the following normative Compared to Section 19.5.1 of [RFC2616], the following normative
changes reflecting actual implementations have been made: changes reflecting actual implementations have been made:
o According to RFC 2616, the disposition type "attachment" only o According to RFC 2616, the disposition type "attachment" only
applies to content of type "application/octet-stream". This applies to content of type "application/octet-stream". This
restriction has been removed, because recipients in practice do restriction has been removed, because recipients in practice do
not check the content type, and it also discourages properly not check the content type, and it also discourages properly
declaring the media type. declaring the media type.
skipping to change at page 12, line 43 skipping to change at page 13, line 5
furthermore risks misinterpreting the actual value. furthermore risks misinterpreting the actual value.
C.4. Implementations (to be removed by RFC Editor before publication) C.4. Implementations (to be removed by RFC Editor before publication)
Unfortunately, as of March 2011, neither the encoding defined in RFCs Unfortunately, as of March 2011, neither the encoding defined in RFCs
2231 and 5987, nor any of the alternate approaches discussed above 2231 and 5987, nor any of the alternate approaches discussed above
was implemented interoperably. Thus, this specification recommends was implemented interoperably. Thus, this specification recommends
the approach defined in RFC 5987, which at least has the advantage of the approach defined in RFC 5987, which at least has the advantage of
actually being specified properly. actually being specified properly.
The table below shows the implementation support for the various The table below shows the support for the various approaches in the
approaches: current implementations:
+---------------+------------+--------+--------------+--------------+ +---------------+------------+--------+--------------+--------------+
| User Agent | RFC | RFC | Percent | Encoding | | User Agent | RFC | RFC | Percent | Encoding |
| | 2231/5987 | 2047 | Encoding | Sniffing | | | 2231/5987 | 2047 | Encoding | Sniffing |
+---------------+------------+--------+--------------+--------------+ +---------------+------------+--------+--------------+--------------+
| Chrome | yes | yes | yes | yes | | Chrome | yes | yes | yes | yes |
| Firefox | yes (*) | yes | no | yes | | Firefox | yes (*) | yes | no | yes |
| Internet | yes (**) | no | yes | no | | Internet | yes (**) | no | yes | no |
| Explorer | | | | | | Explorer | | | | |
| Konqueror | yes | no | no | no | | Konqueror | yes | no | no | no |
| Opera | yes | no | no | no | | Opera | yes | no | no | no |
| Safari | no | no | no | yes | | Safari | no | no | no | yes |
+---------------+------------+--------+--------------+--------------+ +---------------+------------+--------+--------------+--------------+
(*) Does not implement the fallback behavior to "filename" described (*) Does not implement the fallback behavior to "filename" described
in Section 4.3; a fix is planned for Firefox 5. in Section 4.3; a fix is planned for Firefox 5.
(**) Starting with IE9RC, but only implements UTF-8. (**) Starting with Internet Explorer 9, but only implements UTF-8.
Appendix D. Advice on Generating Content-Disposition Header Fields Appendix D. Advice on Generating Content-Disposition Header Fields
To successfully interoperate with existing and future user agents, To successfully interoperate with existing and future user agents,
senders of the Content-Disposition header field are advised to: senders of the Content-Disposition header field are advised to:
o Include a "filename" parameter when US-ASCII is sufficiently o Include a "filename" parameter when US-ASCII ([US-ASCII]) is
expressive. sufficiently expressive.
o Use the 'token' form of the filename parameter only when it does o Use the 'token' form of the filename parameter only when it does
not contain disallowed characters (e.g., spaces); in such cases, not contain disallowed characters (e.g., spaces); in such cases,
the quoted-string form should be used. the quoted-string form should be used.
o Avoid including the percent character followed by two hexadecimal o Avoid including the percent character followed by two hexadecimal
characters (e.g., %A9) in the filename parameter, since some characters (e.g., %A9) in the filename parameter, since some
existing implementations consider it to be an escape character, existing implementations consider it to be an escape character,
while others will pass it through unchanged. while others will pass it through unchanged.
skipping to change at page 14, line 16 skipping to change at page 14, line 21
"filename" parameter as a fallback for user agents that do not "filename" parameter as a fallback for user agents that do not
support the "filename*" form, if possible. This can be done by support the "filename*" form, if possible. This can be done by
substituting characters with US-ASCII sequences (e.g., Unicode substituting characters with US-ASCII sequences (e.g., Unicode
character point U+00E4 (LATIN SMALL LETTER A WITH DIARESIS) by character point U+00E4 (LATIN SMALL LETTER A WITH DIARESIS) by
"ae"). Note that this may not be possible in some locales. "ae"). Note that this may not be possible in some locales.
o When a "filename" parameter is included as a fallback (as per o When a "filename" parameter is included as a fallback (as per
above), "filename" should occur first, due to parsing problems in above), "filename" should occur first, due to parsing problems in
some existing implementations. [[fallbackbug: Firefox is known to some existing implementations. [[fallbackbug: Firefox is known to
pick the wrong parameter; a bug fix is scheduled for Firefox 5. pick the wrong parameter; a bug fix is scheduled for Firefox 5.
--jre]] --jre]] [[NOTE-TO-RFC-EDITOR: PLEASE REMOVE THIS AND THE PRECEDING
COMMENT BEFORE PUBLICATION AS RFC. --jre]]
o Use UTF-8 as the encoding of the "filename*" parameter, when o Use UTF-8 as the encoding of the "filename*" parameter, when
present, because at least one existing implementation only present, because at least one existing implementation only
implements that encoding. implements that encoding.
Note that this advice is based upon UA behaviour at the time of Note that this advice is based upon UA behaviour at the time of
writing, and might be superseded. At the time of publication of this writing, and might be superseded. At the time of publication of this
document, <http://purl.org/NET/http/content-disposition-tests> document, <http://purl.org/NET/http/content-disposition-tests>
provides an overview of current levels of support in various provides an overview of current levels of support in various
implementations. implementations.
skipping to change at page 17, line 12 skipping to change at page 17, line 12
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/278>: o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/278>:
"conformance language" "conformance language"
E.12. Since draft-ietf-httpbis-content-disp-07 E.12. Since draft-ietf-httpbis-content-disp-07
Rephrase the requirement about well-known file system locations, and Rephrase the requirement about well-known file system locations, and
also clarify that by "last path segment" we mean the actual filename. also clarify that by "last path segment" we mean the actual filename.
Added a forward reference from "invalid" to the section that defines Added a forward reference from "invalid" to the section that defines
a valid header field. a valid header field.
E.13. Since draft-ietf-httpbis-content-disp-08
Update: Internet Explorer 9 is released. Various editorial
improvements. Add US-ASCII reference. Strengthen file extension
handling requirement to MUST for those recipients that actually use
file extensions to map media types.
Index Index
C C
Content-Disposition header field 5 Content-Disposition header field 5
H H
Header Fields Header Fields
Content-Disposition 5 Content-Disposition 5
Author's Address Author's Address
 End of changes. 20 change blocks. 
24 lines changed or deleted 40 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/