Re: [secdir] Secdir review of draft-ietf-mediaman-toplevel-03

["Martin J. Dürst" <[e-mail]>]

Hello Radia,

Many thanks for your (mostly) favorable review. Please see below for one 
specific point.

On 2023-10-13 05:22, Radia Perlman wrote:
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
> 
> 
> 
> I would classify this document as "no issues".
> 
> 
> 
> In the list of MIME types (which we're now supposed to call "Media Types"
> to reflect the fact that they are not just for email anymore), there are
> hierarchical names for the various types including things like
> "application/pkix-cert" or "image/bmp". There are thousands of IANA
> registered types like this under a handful of top level types:
> 
> 
> 
> application/
> 
> audio/
> 
> font/
> 
> image/
> 
> message/
> 
> model/
> 
> multipart/
> 
> text/
> 
> video/
> 
> 
> 
> This document describes under what circumstances one would want to create a
> new top level media type (as opposed to a new subtype under one of the
> existing types). This document does not make it unambiguous as to what the
> best approach is, and there is already a description in RFC 6838 which
> seems adequate to me.

I agree that even with the new document, there are no perfect answers 
(i.e. no list to go through mechanically that would make sure that 
anybody arrives at exactly the same conclusion). But I think we narrowed 
things quite a bit.


> It's not clear what the motivation for creating this
> document now is, but as I said it is "mostly harmless".

The direct motivation was the proposal for a new haptic top level type. 
Our AD was suggesting we needed better criteria. It's also in the WG 
charter. There's also a long-term goal of re-issuing RFC 6838 with this 
material integrated. But that's long-term, so no guarantees :-(.

Regards,   Martin.


> It says under security considerations that it's up to the new type
> specification to say what the security implications are for that type,
> which seems about right to me.
> 
> Radia
>