Post-facto reporting of media type security considerations

[Martin Duerst]

The new registration procedure for mime types is at
http://www.ietf.org/internet-drafts/draft-freed-media-type-reg-01.txt.
That doesn't seem to do away with the "Comments on Media Type Registrations".
I agree that this section has some problems. The new registration
process also allows registrations directly from standards bodies
outside the IETF (with IESG approval). While for example the W3C
has a better working system for dealing with errata (there is
a link to an errata page from each W3C Recommendation, and
there is even a direct link for the TR page
(http://www.w3.org/TR/#Recommendations)), that may be different
for other standards organizations. Also, there is not necessarily
a guarantee that a request from IANA for an erratum would be
honored, or that the IANA would know how to go about notifying
the right place if they received a comment.

Regards,     Martin.

P.S.: It seems that our setting of the 'Reply-To' header has
       prompted the IANA anti-spam system to send its message to
       the list rather than to you only. Any way, on either your
       or IANAs side, to avoid that?


At 23:08 04/10/18, Bruce Lilly wrote:
 >[This message has been sent to the ietf-types mailing list with a courtesy
 >copy to IANA (as IANA issues are raised); I have suggested responses
 >be directed to the ietf-types list]
 >
 >There are some media types for which security issues have become known
 >since the original type registrations. RFC 2048 has a provision for reporting
 >such issues:
 >
 >2.2.6.  Security Requirements
 >[...]
 >   The security considerations section of all registrations is subject
 >   to continuing evaluation and modification, and in particular may be
 >   extended by use of the "comments on media types" mechanism described
 >   in subsequent sections.
 >
 >and
 >
 >2.4.  Comments on Media Type Registrations
 >
 >   Comments on registered media types may be submitted by members of the
 >   community to IANA.  These comments will be passed on to the "owner"
 >   of the media type if possible.  Submitters of comments may request
 >   that their comment be attached to the media type registration itself,
 >   and if IANA approves of this the comment will be made accessible in
 >   conjunction with the type registration itself.
 >
 >RFC 2048 was issued nearly eight years ago, so I wonder if the procedure
 >listed there is still considered appropriate.  In particular, I have several
 >questions that members of this list might be qualified to answer:
 >
 >1. Has this mechanism ever been used? [I have scanned several dozen
 >    media registrations, but could find no example of anything that
 >    looks like commentary attached to the media type registration]
 >
 >2. Media types can be registered via a textual form alone, or in an RFC.
 >    It seems unlikely that IANA can attach comments to an RFC, as RFCs
 >    are supposed to remain unchanged once published.  There is a
 >    somewhat obscure errata page, but that's managed by the RFC
 >    Editor, not IANA.  I therefore believe that the RFC 2048 procedure
 >   as written is not entirely adequate. Comments?
 >
 >3. Does IANA itself currently have the expertise to evaluate accuracy
 >    and applicability of submitted comments?  If not, who will IANA
 >    turn to for advice, and would it be prudent/advisable/acceptable
 >    for "submitters of comments" to copy them (assuming that
 >    submission of comments to IANA is still considered the applicable
 >    procedure)?
 >
 >4. The RFC 2048 text mentions that comments will be forwarded to the
 >    media type "owner", and mentions IANA approval of comments.
 >    What procedures exist for conflict resolution? For example, suppose
 >    that the submitter of a textual registration which claimed "no
 >    known security issues" believes in security through obscurity (or
 >    is constrained by such a corporate employer's policy) and objects
 >    to having security comments attached to the registration (assume
 >    that substantial third-party corroboration of real security issues
 >    is provided with the comments); does the type "owner" have
 >    final say in the matter, does IANA have the authority to override
 >    such non-substantive objections, is there provision for IETF AD or
 >    IESG review if necessary, etc.?