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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 12 May 2021 09:21:03 -0700

Comments welcome, including my late-night choice of name.

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

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.

   -

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

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

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

   Consider any issues around media types for programming languages.
   -

   Determine revised criteria regarding Security Considerations sections in
   media type applications.
   -

   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.

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.

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)

---

From: Ned Freed <[email-masked]>
Date: Wed, 12 May 2021 11:53:45 -0700 (PDT)

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

> current processes don’t make it clear how this request should be evaluated

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.

> up the following work.  The working group has discretion to order these as

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.

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

>    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

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.

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

> review team.  If so, the working group will negotiate a new charter

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.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 12 May 2021 14:28:44 -0700

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

> [...]

Will edit accordingly.

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

> As for criteria, I guess we could try and codify some, but again,

I can soften this one.

> So the task is to develop such a checklist, not to revise the criteria

Ack.

> core specification; I don't think we should assume a revision is needed for

Fair enough.

> 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

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 13 May 2021 08:59:18 +0900

Hello Ned, Murray, others,

> made that we don't know how to do this.

RFC 8081 is definitely a very good model. In particular, it contains a 
whole series of subtype registrations. As to "fairly smoothly", it 
actually took a long time, mostly to find the right editor (Chris 
Lilley) and to get the relevant community behind it. That happened in 
the context of the Web Font work at W3C.

> As for criteria, I guess we could try and codify some, but again,

Agree with Ned here.

>>     based on draft-muthusamy-dispatch-haptics.

I think it's okay as written. It might be appropriate to mention 
interactions with other types (audio, video,.. have been mentioned).

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

I'm not really sure this has to be contentious. And the communities who 
want it may also have some timing preferences.

Anyway, while we are at it, can we make sure an announcement of this 
charter proposal (or a next version) also goes to [email-masked], 
because some people interested in this work may be on that list but not 
(yet) on the dispatch list.

> core specification; I don't think we should assume a revision is needed for

Wasn't there also talk about tweaking the registration template, to 
adjust for changes in how file types are handled on various operating 
systems? Not sure which document that would affect.

> to consider the alternatives (mailing list, directorate, ?) first.

I agree with Ned.

Regards,   Martin.

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 16 May 2021 14:41:42 +1000

Agreeing with Ned's comments.

One thing that I'd like to see discussed (not necessarily in this proposed WG, although that might be an appropriate venue for it) is whether the interface for registration (from the perspective of a prospective registrant) can be updated (or augmented). In particular, many in the W3C still finds the registration process painful and bewildering, and I strongly suspect that others do not undertake registrations for the same reasons.

We've now had a fair amount of experience using GitHub as both a registration interface and for managing the processing of requests, both for link relations and well-known URIs:

https://github.com/protocol-registries/link-relations
https://github.com/protocol-registries/well-known-uris

I think the media subtype registry is a good candidate for this approach too; its audience is much larger than those who are familiar with the IETF, and so effectively what we're doing is adding a web-based registration request flow to make it easier and more transparent for those people.

Thoughts?

> On 13 May 2021, at 4:53 am, Ned Freed <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/