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

[Ned Freed <[e-mail]>]

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

> -MSK

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

   font - RFC 8081 - 2017
   example - RFC 4735 - 2006
   model - RFC 2077 - 1997

AFAICR the process for font went fairly smoothly - which is why I keep pointing
to RFC 8081 as a model for how to do it - so I'm not sure there's a case to be
made that we don't know how to do this.

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

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

>    Develop and process the pending ‘haptics’ top-level media type request,
>    based on draft-muthusamy-dispatch-haptics.

+1

>    Consider whether and how to permit multiple media type suffixes.

I think this one is likely to be the most contentious by far, and should come
last.

>    Consider any issues around media types for programming languages.

+1

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

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

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

> Input Document(s):

>    -

>    draft-muthusamy-dispatch-haptics


> Proposed milestones (target dates TBD):

>    -

>    draft-muthusamy-dispatch-haptics (or equivalent) to the IESG for
>    approval (Proposed Standard)
>    -

>    RFC6838bis to the IESG for approval (BCP)