Skip to main content

Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)
draft-ietf-httpbis-content-disp-09

Revision differences

Document history

Date Rev. By Action
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Sean Turner
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Stewart Bryant
2012-08-22
09 (System) post-migration administrative database adjustment to the Yes position for Peter Saint-Andre
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for David Harrington
2011-04-06
09 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Hilarie Orman.
2011-04-05
09 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2011-04-05
09 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2011-04-05
09 (System) IANA Action state changed to In Progress from Waiting on Authors
2011-03-28
09 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2011-03-28
09 (System) IANA Action state changed to Waiting on Authors from In Progress
2011-03-28
09 (System) IANA Action state changed to In Progress
2011-03-28
09 Cindy Morgan IESG state changed to Approved-announcement sent
2011-03-28
09 Cindy Morgan IESG has approved the document
2011-03-28
09 Cindy Morgan Closed "Approve" ballot
2011-03-28
09 Cindy Morgan Approval announcement text regenerated
2011-03-28
09 Alexey Melnikov Ballot writeup text changed
2011-03-28
09 (System) New version available: draft-ietf-httpbis-content-disp-09.txt
2011-03-25
09 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2011-03-18
09 David Harrington [Ballot comment]
I cleared
2011-03-18
09 David Harrington [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss
2011-03-17
09 Cindy Morgan Removed from agenda for telechat
2011-03-17
09 Cindy Morgan State changed to IESG Evaluation::AD Followup from IESG Evaluation.
2011-03-17
09 Alexey Melnikov Ballot writeup text changed
2011-03-17
09 Alexey Melnikov Ballot writeup text changed
2011-03-17
09 Sean Turner
[Ballot discuss]
(updated based on RFC editor notes)

#1) Sec 3.1 contains the following:

  Recipients MAY take steps to recover a usable field-value from …
[Ballot discuss]
(updated based on RFC editor notes)

#1) Sec 3.1 contains the following:

  Recipients MAY take steps to recover a usable field-value from an
  invalid header field, but SHOULD NOT reject the message outright,
  unless this is explicitly desirable behaviour (e.g., the
  implementation is a validator).  As such, the default handling of
  invalid fields is to ignore them.

What's the default requirement?  It needs to be reworded as follows:

  As such, implementations SHOULD ignore invalid field by default.
2011-03-17
09 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to Discuss from No Objection
2011-03-17
09 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2011-03-17
09 Alexey Melnikov Ballot writeup text changed
2011-03-17
09 Alexey Melnikov Ballot writeup text changed
2011-03-17
09 Alexey Melnikov Ballot writeup text changed
2011-03-17
09 Alexey Melnikov Ballot writeup text changed
2011-03-17
09 Sean Turner
[Ballot discuss]
(updated based on exchanges with author)

#1) Sec 3.1 contains the following:

  Recipients MAY take steps to recover a usable field-value from …
[Ballot discuss]
(updated based on exchanges with author)

#1) Sec 3.1 contains the following:

  Recipients MAY take steps to recover a usable field-value from an
  invalid header field, but SHOULD NOT reject the message outright,
  unless this is explicitly desirable behaviour (e.g., the
  implementation is a validator).  As such, the default handling of
  invalid fields is to ignore them.

What's the default requirement?  It needs to be reworded as follows:

  As such, implementations SHOULD ignore invalid field by default.

#2) Sec 4.3 contains the following:

  Thus, recipients SHOULD ensure
  that a file extension is used that is safe, optimally matching the
  media type of the received payload.

Why isn't this MUST.  An implementation that doesn't do this is then vulnerable to the attacks you just described.  Under what circumstances is this a good idea?
2011-03-17
09 Stewart Bryant
[Ballot comment]
"RFC 2616 defines the Content-Disposition response header field"

I think that you need to say the  Content-Disposition response header field of what. Same …
[Ballot comment]
"RFC 2616 defines the Content-Disposition response header field"

I think that you need to say the  Content-Disposition response header field of what. Same for Intro.

=====

Changed from Discuss to Comment

When the value contains path separator characters ("\" or "/"),
      recipients SHOULD ignore all but the last path segment.  This
      prevents unintentional overwriting of well-known file system
      locations (such as "/etc/passwd").

... or even intentionally over writing it - depending on your perspective.

I spent a little time puzzling over the /etc/passwd case. Since /etc/ looked
like the last path segment. However I think that you mean that the file
will be stored in "some-default-directory-but-not-slash/etc/passwd". It would
be useful to clarify this in the text with an example.

Why is this a SHOULD and not a MUST given the security implications.

====

Surely the security section (or 4.3) needs to discuss file permissions as well as well known extension types.
2011-03-17
09 Stewart Bryant [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss
2011-03-17
09 Sean Turner
[Ballot comment]
#1) Sec 4.1 contains the following phrase:

  Furthermore note that the format used for ext-value allows specifying
  a natural language;

It …
[Ballot comment]
#1) Sec 4.1 contains the following phrase:

  Furthermore note that the format used for ext-value allows specifying
  a natural language;

It would greatly help to include an "natural language (e.g., );"

#3) Sec 8.2: Should the registration template include:

  Related information: none

#5) App D contains the following:

    [[fallbackbug: Firefox is known to
      pick the wrong parameter; a bug fix is scheduled for Firefox 5.
      --jre]]

Is this supposed to be removed?
2011-03-17
09 Sean Turner
[Ballot discuss]
(updated based on exchanges with author)

#1) Sec 3.1 contains the following:

  Recipients MAY take steps to recover a usable field-value from …
[Ballot discuss]
(updated based on exchanges with author)

#1) Sec 3.1 contains the following:

  Recipients MAY take steps to recover a usable field-value from an
  invalid header field, but SHOULD NOT reject the message outright,
  unless this is explicitly desirable behaviour (e.g., the
  implementation is a validator).  As such, the default handling of
  invalid fields is to ignore them.

What's the default requirement?  It needs to be reworded as follows:

  As such, implementations SHOULD ignore invalid field by default.

#2) Sec 4.3 contains the following:

  Thus, recipients SHOULD ensure
  that a file extension is used that is safe, optimally matching the
  media type of the received payload.

Why isn't this MUST.  An implementation that doesn't do this is then vulnerable to the attacks you just described.  Under what circumstances is this a good idea?

#3) Sec 4.1 contains the following:

  Header field values with multiple instances of the same parameter
  name are invalid.

Is this a new requirement on HTTP headers or is this true of all HTTP headers?
2011-03-17
09 Sean Turner
[Ballot comment]
#1) Sec 4.1 contains the following phrase:

  Furthermore note that the format used for ext-value allows specifying
  a natural language;

It …
[Ballot comment]
#1) Sec 4.1 contains the following phrase:

  Furthermore note that the format used for ext-value allows specifying
  a natural language;

It would greatly help to include an "natural language (e.g., );"

#2) Sec 4.3 contains the following phrase:

  ... a natural language ...

Could you provide and (e.g., ).  I didn't parse what this was.

#3) Sec 8.2: Should the registration template include:

  Related information: none

#4) App C.4 contains a table listing browsers, without version #s this table isn't of much use it - or is it all version?

#5) App D contains the following:

    [[fallbackbug: Firefox is known to
      pick the wrong parameter; a bug fix is scheduled for Firefox 5.
      --jre]]

Is this supposed to be removed?
2011-03-17
09 Sean Turner
[Ballot discuss]
#1) Sec 3.1 contains the following:

  Recipients MAY take steps to recover a usable field-value from an
  invalid header field, but …
[Ballot discuss]
#1) Sec 3.1 contains the following:

  Recipients MAY take steps to recover a usable field-value from an
  invalid header field, but SHOULD NOT reject the message outright,
  unless this is explicitly desirable behaviour (e.g., the
  implementation is a validator).  As such, the default handling of
  invalid fields is to ignore them.

What's the default requirement?  It needs to be reworded as follows:

  As such, implementations SHOULD ignore invalid field by default.

#2) Sec 4.3 contains the following:

  Thus, recipients SHOULD ensure
  that a file extension is used that is safe, optimally matching the
  media type of the received payload.

Why isn't this MUST.  An implementation that doesn't do this is then vulnerable to the attacks you just described.  Under what circumstances is this a good idea?

#3) Sec 4.1 contains the following:

  Header field values with multiple instances of the same parameter
  name are invalid.

Is this a new requirement on HTTP headers or is this true of all HTTP headers?

#4) Appendix D: Need normative reference for US-ASCII.
2011-03-17
09 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded
2011-03-17
09 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded
2011-03-16
09 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-03-16
09 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2011-03-16
09 Alexey Melnikov
[Ballot comment]
In answer to David's DISCUSS:

1) This document doesn't need to update or obsolete RFC 2183, because RFC 2183 specifies Content-Disposition header …
[Ballot comment]
In answer to David's DISCUSS:

1) This document doesn't need to update or obsolete RFC 2183, because RFC 2183 specifies Content-Disposition header field for email only. This draft is a standalone version for HTTP.

2) This document is not obsoleting/updating any other HTTPBIS WG I-D.

3) Yes, both filename and filename*  are allowed. That is intentional (for backward compatibility)

4) The editor answered this, but there was a small edit in the document to add the cross reference.
2011-03-16
09 Alexey Melnikov
[Ballot comment]
To answer to David's DISCUSS:

1) This document doesn't need to update or obsolete RFC 2183, because RFC 2183 specifies Content-Disposition header …
[Ballot comment]
To answer to David's DISCUSS:

1) This document doesn't need to update or obsolete RFC 2183, because RFC 2183 specifies Content-Disposition header field for email only. This draft is a standalone version for HTTP.

2) This document is not obsoleting/updating any other HTTPBIS WG I-D.

3) Yes, both filename and filename*  are allowed. That is intentional (for backward compatibility)

4) The editor answered this, but there was a small edit in the document to add the cross reference.
2011-03-16
09 Peter Saint-Andre [Ballot Position Update] Position for Peter Saint-Andre has been changed to Yes from Discuss
2011-03-16
09 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2011-03-16
09 Adrian Farrel
[Ballot comment]
I have no objection to the publication of this document. There are a couple f small points that I think would benefit from …
[Ballot comment]
I have no objection to the publication of this document. There are a couple f small points that I think would benefit from attention first.

---

Section 2 says that BNF from RFC 2616 is used.
Section 3 metnions "ABNF". Is this the same (in which case please use
consistent terminology) or different (in which case please supply a
reference for ABNF).

(See also Peter's Discuss

---

Section 4.3 contains a number of bullets. The first one uses RFC 2119
language to specify behavior, but the remaining bullets use apple-pie
language. Do you need to upgrade all bullets to RFC 2119?
2011-03-16
09 Peter Saint-Andre
[Ballot discuss]
I have one question I'd like to discuss. The forthcoming documents from the HTTPBIS WG use ABNF as defined in RFC 5234. …
[Ballot discuss]
I have one question I'd like to discuss. The forthcoming documents from the HTTPBIS WG use ABNF as defined in RFC 5234. Why does this document use the definition from Section 2.1 of RFC 2616?
2011-03-16
09 Peter Saint-Andre [Ballot Position Update] New position, Discuss, has been recorded
2011-03-15
09 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2011-03-15
09 Alexey Melnikov State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-03-14
08 (System) New version available: draft-ietf-httpbis-content-disp-08.txt
2011-03-14
09 David Harrington
[Ballot comment]
1) I agree with Stewart's DISCUSS. I found the discussion of the last segment of the filename to be confusing.

2) I agree …
[Ballot comment]
1) I agree with Stewart's DISCUSS. I found the discussion of the last segment of the filename to be confusing.

2) I agree with Stewart's concern about some additional security considerations that are not documented.
2011-03-14
09 David Harrington
[Ballot discuss]
1) is this document meant to update or obsolete 2183 (or not)? Per appendix B, this document omits parameters specified in 2183. Is …
[Ballot discuss]
1) is this document meant to update or obsolete 2183 (or not)? Per appendix B, this document omits parameters specified in 2183. Is this meant to obsolete those parameters?

2) "This specification is expected to replace the definition of Content-
  Disposition in the HTTP/1.1 specification, as currently revised by
  the IETF HTTPbis working group."
Does this document obsolete/update the I-Ds being produced by httpbis? If so, which drafts?

3) Does the grammar in 4.1 allow both filename and filename*  to be specified?

4) I think the statement "  Senders MUST NOT generate Content-Disposition header fields that are
  invalid." should include a pointer to the specific rules about what is invalid.
2011-03-14
09 David Harrington [Ballot Position Update] New position, Discuss, has been recorded
2011-03-14
09 Robert Sparks
[Ballot comment]
Consider adding "At the time of publication of this document, " to the front of the sentence starting with the purl.org URL at …
[Ballot comment]
Consider adding "At the time of publication of this document, " to the front of the sentence starting with the purl.org URL at the end of Appendix D. Using a tool like purl.org helps make it easier to manage moving content around, but won't guarantee that that the content isn't a dangling reference or that it contains relative content in 20 years.
2011-03-14
09 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-03-14
09 Dan Romascanu
[Ballot comment]
Why would Appendix C4 be removed at publication? I believe that it actually includes important information about the status of the implementations, and …
[Ballot comment]
Why would Appendix C4 be removed at publication? I believe that it actually includes important information about the status of the implementations, and clarifies the reasons of some of the choices made by editors and the WG.
2011-03-14
09 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2011-03-14
09 Stewart Bryant
[Ballot comment]
"RFC 2616 defines the Content-Disposition response header field"

I think that you need to say the  Content-Disposition response header field of what. Same …
[Ballot comment]
"RFC 2616 defines the Content-Disposition response header field"

I think that you need to say the  Content-Disposition response header field of what. Same for Intro.
2011-03-14
09 Stewart Bryant
[Ballot discuss]
When the value contains path separator characters ("\" or "/"),
      recipients SHOULD ignore all but the last path segment.  This …
[Ballot discuss]
When the value contains path separator characters ("\" or "/"),
      recipients SHOULD ignore all but the last path segment.  This
      prevents unintentional overwriting of well-known file system
      locations (such as "/etc/passwd").

... or even intentionally over writing it - depending on your perspective.

I spent a little time puzzling over the /etc/passwd case. Since /etc/ looked
like the last path segment. However I think that you mean that the file
will be stored in "some-default-directory-but-not-slash/etc/passwd". It would
be useful to clarify this in the text with an example.

Why is this a SHOULD and not a MUST given the security implications.

====

Surely the security section (or 4.3) needs to discuss file permissions as well as well known extension types.
2011-03-14
09 Stewart Bryant [Ballot Position Update] New position, Discuss, has been recorded
2011-03-14
07 (System) New version available: draft-ietf-httpbis-content-disp-07.txt
2011-03-14
09 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-03-09
09 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2011-03-09
09 Alexey Melnikov Ballot has been issued
2011-03-09
09 Alexey Melnikov Created "Approve" ballot
2011-03-09
09 Alexey Melnikov [Note]: 'Mark Nottingham (HTTPBIS chair) is the document shepherd' added
2011-03-09
09 Alexey Melnikov
  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
  …
  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Mark Nottingham (HTTPbis WG Chair). I believe this document is ready for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

It has been reviewed by core WG members and browser implementers.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

Not all current implementations fully support the internationalisation features here (see the appendix). However, I believe this document represents the best we can do without more active vendor involvement, and it represents a significant improvement over the existing specification of this header.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

Most of the work was done by Julian Reschke, but various implementers were involved in the discussion, as well as other WG members.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Yes.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

References are split. No dangling or downwards references.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA Considerations section is present and in order.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

Yes.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard.  This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects.

    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

During Last Call, it was asserted that the draft should also specify error handling for browsers in detail. We improved some aspects of this in ways that were compatible with existing behaviour, but did not attempt to proactively specify additional error handling, as we didn't see broad engagement in the discussion from implementers. This resolution was not contentious.

    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

There are many existing implementations; see . Based on public statements and bug activity, we believe that implementations will continue to improve.
2011-03-04
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Hilarie Orman
2011-03-04
09 Samuel Weiler Request for Last Call review by SECDIR is assigned to Hilarie Orman
2011-03-04
09 Amanda Baber

IANA understands that, upon approval of this document, there is a single
IANA Action that needs to be completed.

In the Permanent Message Header Field …

IANA understands that, upon approval of this document, there is a single
IANA Action that needs to be completed.

In the Permanent Message Header Field Names registry located at:

http://www.iana.org/assignments/message-headers/perm-headers.html

the Content-Disposition HTTP header field in the permanent HTTP header
field registry will be updated as follows:

Header field name: Content-Disposition
Applicable protocol: http
Status: standard
Author/Change controller: IETF
Specification document: [ RFC-to-be ]

IANA understands that this is the only action that needs to be completed
upon approval of this document.
2011-02-28
09 Amy Vezza Last call sent
2011-02-28
09 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)) to Proposed Standard


The IESG has received a request from the Hypertext Transfer Protocol Bis
WG (httpbis) to consider the following document:
- 'Use of the Content-Disposition Header Field in the Hypertext Transfer
  Protocol (HTTP)'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-03-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-httpbis-content-disp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-httpbis-content-disp/

2011-02-28
09 Alexey Melnikov Placed on agenda for telechat - 2011-03-17
2011-02-28
09 Alexey Melnikov Last Call was requested
2011-02-28
09 Alexey Melnikov State changed to Last Call Requested from AD Evaluation.
2011-02-28
09 (System) Ballot writeup text was added
2011-02-28
09 (System) Last call text was added
2011-02-28
09 (System) Ballot approval text was added
2011-02-28
09 Alexey Melnikov State changed to AD Evaluation from AD is watching::AD Followup.
2011-02-26
06 (System) New version available: draft-ietf-httpbis-content-disp-06.txt
2011-02-17
05 (System) New version available: draft-ietf-httpbis-content-disp-05.txt
2010-11-23
09 Alexey Melnikov Draft Added by Alexey Melnikov in state AD is watching
2010-11-12
04 (System) New version available: draft-ietf-httpbis-content-disp-04.txt
2010-10-25
03 (System) New version available: draft-ietf-httpbis-content-disp-03.txt
2010-09-22
02 (System) New version available: draft-ietf-httpbis-content-disp-02.txt
2010-09-16
01 (System) New version available: draft-ietf-httpbis-content-disp-01.txt
2010-09-03
00 (System) New version available: draft-ietf-httpbis-content-disp-00.txt