I'm going to start with a thought experiment. Suppose there was a draft in last call that claimed to specify something like a cryptographic hash function, symmetric cipher, SNMP MIB, or perhaps even an application protocol. However, instead of actually defining this thing, it instead referred the reader to a couple of web pages - not IETF web pages, but pages owned by the corporation behind the registration. In fact the only real function of the document was to assign identifiers owned by the IETF, in effect attaching an IETF imprimatur to this thing. In fact the draft didn't even assign change control of the actual specification to the IETF. How do you think such a draft would fare? I'm thinking "not very well". But this is essentially what's being done here. This draft doesn't specify the image format it is registering. All it really does is register a media type name in the standards tree for the format, with the IETF being the associated standards body but not the change controller. And it's not like there are no other options. The obvious one is to simply register this media type in the vendor tree. Easy-peasy, fill in the form at IANA, no document required. If the issue with this being a vendor registration is that the unfaceted (no "vnd." prefix) name is already in wide use, well, we have an exception process for that. RFC 6838 Appendix A states: From time to time there may also be cases where a media type with an unfaceted subtype name has been widely deployed without being registered. (Note that this includes subtype names beginning with the "x-" prefix.) If possible, such a media type SHOULD be reregistered with a proper faceted subtype name, possibly using a deprecated alias to identify the original name (see Section 4.2.9). However, if this is not possible, the type can, subject to approval by both the media types reviewer and the IESG, be registered in the proper tree with its unfaceted name. If for some reason this really needs to be in the standards tree, another option would be to properly document the format in the RFC. Maybe I'm missing something, but I don't see why the relevant web pages could not be turned into RFC text. I also note that the RFC Errata system could then be used to track any errors that are found. One final note. The current security considerations in this draft need work no matter what is done. They currently say: Security risks are similar to other media content and may include buffer overruns and uninitialized data usage as part of the demuxing and decoding process [cve.mitre.org-libwebp] [crbug-security]. Seriously, similar? The issues listed are ones associated with implementation errors, and that should be explicitly stated. The obvious risk associated with compressed types is that malicious content can often be constructed that expanded to something vastly larger than the original. Other potential risks with image types include the ability to include executable content in the data stream. (I don't think this is a risk with this particular type, but if so it should be stated that it isn't.) And it should be noted whether or not the type itself provides any sort of privacy or integrity protection. Ned -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
