> > 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
