Re: [dispatch] Proposed/draft charter for "mediaman"

["Murray S. Kucherawy" <[e-mail]>]

On Wed, May 12, 2021 at 12:52 PM Ned Freed <[e-mail]> wrote:

> > Comments welcome, including my late-night choice of name.
>
> The name is fine. The rest... I'm afraid I have a lot of problems with it.
>

That's OK, that's what feedback is for.  I'd break my arm patting myself on
the back if I somehow got this right on the first go.

> Media Type Maintenance (“MEDIAMAN”) Working Group Charter [DRAFT]
>
> > The IETF maintains a registry of media types and subtypes that are used
> to
> > identify particular payloads and their semantics as they are transported
> > via application level protocols such as messaging (“email”) and the web
> > (HTTP).  The core structure and use of media types is the MIME framework,
> > defined in RFCs 2045 through 2049, and amended by various later
> documents.
> > Registration of new media types is defined by BCP 13, which was last
> > updated in 2013.
>
> > Several topics have appeared in the interim that are large enough in
> scope
> > and importance to warrant the formation of a working group to develop and
> > process them.  In particular, we have for the first time a request for a
> > new top-level media type, and such requests are sufficiently rare that
> our
> > current processes don’t make it clear how this request should be
> evaluated
> > and dispatched.
>
> It's not the first top-level type we've added:
> [...]
>

Will edit accordingly.

> This working group will therefore, under this instance of the charter,
> take
> > up the following work.  The working group has discretion to order these
> as
> > appropriate.
>
> Strongly disagree. If the haptics work is time-sensitive - and I think
> there's a
> consensus that it is - the charter needs to say it comes first and will be
> completed before starting the other work.
>

OK by me.  Since I was under the mistaken impression that the process for
making new top-level types was untried, this seemed to be the right
ordering, but I'll adjust.

ACK on the rest of your comments.  I'll wait a day or so for other feedback
to come in and then post a revision.

>    Establish criteria and procedures for registering top-level media
> >    types.  In particular, specify whether these requests can be handled
> by the
> >    current IANA media type review team, require IETF Consensus, or should
> >    follow some other process.
>
> RFC 6838 is pretty clear on the process: New top-level types require a
> standards-track RFC. AFAIK nobody has argued that we need to revisit this
> approach; especially if we're concerned about getting haptics done in a
> timely
> way.
>
> As for criteria, I guess we could try and codify some, but again,
> timing.
>

I can soften this one.

>    Determine revised criteria regarding Security Considerations sections
> in
> >    media type applications.
>
> Not what I proposed. I've used a checklist to evaluate security
> considerations
> for media types for years; in one of his registrations Eric Prud'hommeaux
> noted
> this and essentially suggested that it would be good to expose a more
> general
> version of it. (Actually, he suggested doing it in the form itself, but a
> checklist needs to come first.)
>
> So the task is to develop such a checklist, not to revise the criteria
> themselves.
>

Ack.

>    Review the format of the media types registry itself.
>
> > It is expected that the working group will produce a document updating
> RFC
> > 6838 (BCP 13) as a result of the points above, and a “haptics” standards
> > track registration RFC.  Any other work is out of scope.
>
> Strongly disagree. The only work I think this group should do that might
> possibly necessitate a revision to BCP 13 is the multiple suffix work. In
> the
> past we managed to add suffixes to media types without needing to revise
> the
> core specification; I don't think we should assume a revision is needed for
> this.
>

Fair enough.


> > On completion of these goals, the working group will discuss whether it
> > would be appropriate for this to become a standing (perhaps usually
> > dormant) working group containing the expertise needed to repeat these
> > reviews periodically, and/or to handle those applications such as the
> > top-level request that are too large in scope for the IANA media type
> > review team.  If so, the working group will negotiate a new charter
> > accordingly.
>
> OK... Maybe this is just me remembering things past that don't apply
> to the brave new IETF world, but I was under the impression that
> We Just Don't Do This. And if we're going to do this, we need
> to consider the alternatives (mailing list, directorate, ?) first.
>

Just a straw man.  I'm fine with those alternatives, although the mailing
list(s) already exist (one for IETF, one for IANA).

I'll wait a day or two for other comments to come in and then I'll post a
revision.

-MSK