perhaps a more useful mode of discussion would be to determine what criteria
should be used for the rfc publication process and whether incremental
improvements are possible, independent of encoding changes.
When someone submits a new Content-disposition value or parameter
registration -- http://xml.resource.org/public/rfc/html/rfc2183.html --
the Area Directors and IESG would be best served to refrain from deferring
the registration decision to secretive industry consortia who have only to
do with one of the many uses of the header.
First of all, since IANA is the resistration agency specified by RFC 2183, you
appear to be asserting that IANA is "a secretive industry consortia". If so, I
completely disagree with this characterization. IANA isn't secretive and it
isn't an industry industria in any sense that I understand the words.
Second, you appear to be assigning a lot more weight to the registration
"decision" than it deserves. This is a *registration* process. That means you
say "I want this registered" and IANA checks to see that it doesn't conflict
with anything that's already there, and if it doesn't it says "OK".
Now, having said that, I will also point out that RFC 2183 is unfortunately a
bit behind the times in terms of registration procedures. In particular, the
registration of such things as type and disposition parameters has been shown
to have nontrivial technical repercussions in fair number of cases. IANA has
neither the expertise nor the desire to perform technical evaluations of this
sort, so when they come up they usually contact the IESG and ask how to
proceed.
The way more modern registration procedures work is that the IANA refers
registrations it receives to a reviewer appointed by the IESG. The reviewer
then reviews the request, applying the registration criteria specified by the
relevant standard. If the registration meets those criteria it is approved, it
not it is returned with an explanation of what is wrong and how to fix it.
IANA's contribution to this sort of registration is to handle the purely
administrative aspects of this process.
When RFC 2183 is next revised its registration procedure should be updated to
bring it into alignment with similar procedures for things like media types,
charsets, and languages. I also note that the review criteria probably need to
be spelled out in more detail.
Does anyone disagree? If so, why?
I certainly do. See above.
If not, I will re-submit the "device" parameter registration.
Not having seen any previous attempt to register a "device" content-disposition
parameter, I'm not clear on what you're talking about here. If you're referring
to your http://www.bovik.org/device-upload.html proposal, as far as I can tell
that doesn't specify a device content-disposition parameter. Device is an HTML
attribute, which is an entirely different thing.
Perhaps you've revised this proposal so it uses a new "device"
content-disposition parameter. If that's the case, while I see no obvious
procedural problem with the registration separate from the overall proposal, I
have to wonder what the value of such a parameter is in isolation. It seems
tightly coupled to the proposal as a whole and unless the entire proposal is
approved (and that appears to be a W3C and not IETF matter) I'm not sure what
value it has.
Ned