Subject: [media-types] Content-Disposition registry backfill

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Aug 2021 09:53:03 -0700

Colleagues,

There's a registry of valid Content-Disposition header values here:

https://www.iana.org/assignments/cont-disp/cont-disp.xhtml

Like the rest of MIME, it was originally created for mail but extended to
use in other things like HTTP and SIP.  The registry was created by RFC
2183.  There have been several registrations made, as you can see.

RFC 2183 (published in 1997) specified a column called "Allowed values" or
something close to that.  As far as IANA can tell, this was overlooked and
never added to the registry.  As a result, all of the registrations since
then have followed the form of the registry rather than the RFC and haven't
specified it.  This went unnoticed in the intervening years.  Then
recently, a document actually followed the registration template, which
highlighted this discrepancy when it came to the IESG for evaluation and
IANA asked us how to resolve it.

I've gone through all of the registering documents, and I believe the
correct way to fill out the registry retroactively is to ask IANA to update
it by adding the column and populating values as shown below.  The IESG
plans to take this up as a management item at its next telechat to approve
it and send that request to IANA.  If anyone would like to suggest a
different path to fixing this, please reply on this thread.

Longer-term, should we consider simply removing the column if, as is
apparent, it seems the community hasn't found it to be important?

Here's the list:

inline: (none)

attachment: filename, creation-date, modification-date, read-date, size,
handling

form-data: name, filename

signal: handling

alert: handling

icon: handling

render: handling

recipient-list-history: handling

session: handling

aib: handling

early-session: (none)

recipient-list: (none)

notification: (none)

by-reference: handling

info-package: (none)

recording-session: (none)

-MSK, ART AD