Subject: [media-types] WG Review: Media Type Maintenance (mediaman)

From: The IESG <[email-masked]>
Date: Fri, 02 Jul 2021 10:53:00 -0700

A new IETF WG has been proposed in the Applications and Real-Time Area. The
IESG has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send your
comments to the IESG mailing list ([email-masked]) by 2021-07-12.

Media Type Maintenance (mediaman)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  TBD

Assigned Area Director:
  Murray Kucherawy <[email-masked]>

Applications and Real-Time Area Directors:
  Murray Kucherawy <[email-masked]>
  Francesca Palombini <[email-masked]>

Mailing list:
  Address: [email-masked]
  To subscribe: https://www.ietf.org/mailman/listinfo/media-types
  Archive: https://mailarchive.ietf.org/arch/browse/media-types/

Group page: https://datatracker.ietf.org/group/mediaman/

Charter: https://datatracker.ietf.org/doc/charter-ietf-mediaman/

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

The registration of a top-level media type is a rare event.  BCP 13 describes
the process for doing so, as was used in RFC 8081, but it does not provide
any guidance or criteria regarding what constitutes an appropriate
registration.

Several other 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.  This working group will therefore take up the following
items, in this order (or as otherwise negotiated with the supervising Area
Director):

* Determine whether any specific criteria or guidance are warranted to handle
registration of future top-level media types, and publish any such guidance.

* Develop and process the pending ‘haptics’ top-level media type request,
based on draft-muthusamy-dispatch-haptics, and the outcome of the previous
work item.

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

* Develop a reviewer’s checklist regarding Security Considerations sections
in media type applications.

* Consider any issues around media types for programming languages.

* Review the format of the media types registry itself.

* Evaluate the registry policies and procedures in the context of how media
types are currently used, and modify them if necessary.

This last item will consider the existing use of GitHub for managing
registrations and the processing queues for the “link relations” and “well
known URIs” registries as examples.

Input Document(s):
* draft-muthusamy-dispatch-haptics

* draft-w3cdidwg-media-types-with-multiple-suffixes

Proposed milestones (target dates TBD):
* Publish any specific criteria or guidance for handling registration of
future top-level media types, either as an RFC or a wiki page.

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

* A draft about handling multiple suffixes to the IESG for approval (BCP)

* Publish a reviewer’s checklist about Security Considerations in media type
applications, either as an RFC or a wiki page.

* Deliver recommendations about the media types registry format.

* Deliver any recommendations about future registration and queue management.

Milestones:

TBD

---

From: tom petch <[email-masked]>
Date: Sun, 4 Jul 2021 21:12:56 +0100

A small tweak.

Most of the discussions I see about media types relate to NETCONF and 
YANG.  The text below talks of programming languages.  I would like that 
expanded to be clear that it includes YANG, if not all such DDL.

The registrations thereof might have been different had multiple 
suffixes been specified.

Tom Petch

On 02/07/2021 18:53, The IESG wrote:
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Ned Freed <[email-masked]>
Date: Sun, 04 Jul 2021 15:17:24 -0700 (PDT)

WFM.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 5 Jul 2021 13:24:31 +0100

> WFM.
+1
> media-types mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/media-types

---

From: Larry Masinter <[email-masked]>
Date: Sun, 11 Jul 2021 13:53:40 -0700

I wrote an ID about MIME and web updates (in 2011):

https://www.ietf.org/archive/id/draft-masinter-mime-web-info-02.txt

I'd hoped also to review MIME Multipart for more modern uses (shades of WPACK)
https://mailarchive.ietf.org/arch/msg/wpack/EixjYebQDTdbcDS6FsE0eZye4ds/

although they haven't taken up my suggestion. Perhaps mediaman could take up such review?

Larry
--
https://LarryMasinter.net https://interlisp.org

> >> > IANA maintains a registry of media types and subtypes that are used
> >> > to identify particular payloads and their semantics as they are
> >> transported via
> >> > This last item will consider the existing use of GitHub for
> >> > managing registrations and the processing queues for the “link
> relations”
> >> and “well

---

From: Ned Freed <[email-masked]>
Date: Sun, 11 Jul 2021 14:36:36 -0700 (PDT)

> https://www.ietf.org/archive/id/draft-masinter-mime-web-info-02.txt

There's a lot here, but the only thing that seems relevant to this
effort is section 5.3:

   Problem: Internet Media Type registries are hard to update, and there
   can be different definitions of the same MIME type.

   STRAWMAN: Allow commenting or easier update; not all Internet Media
   Type owners need or have all the information the internet needs.
   Wiki for Internet Media Types as well as formal registry?  Ability to
   add comments about deployed senders, deployed content, deployed
   recievers.

First, the process to update a registration is the owner sends in an update.
For whatever reason we went a long time with few if any updates, but the rate
now seems to be increasing.

I can't recall a case where an update was difficult to deal with or ended up
being rejected. There have been occasional blips regarding ownership, but
again, I can't recall a case where a resolution was difficult to reach.

tl;dr I remain to be convinced that there's a problem to solve here.

As for comments, I don't have any problem with offering such a service, but I'm
skeptical that the desire to comment (in a constructive way) on media types is
sufficiently widespread that it would be useful.

> although they haven't taken up my suggestion. Perhaps mediaman could take up

I'm sorry, but I *really* don't see the point. The advantages of multipart are
simplicity and fallback behavior. You lose both of those big-time with WPACK,
leaving you with just another way to package stuff. And like it or not, ZIP
seems to have won that battle.

				Ned

---

From: Larry Masinter <[email-masked]>
Date: Sun, 11 Jul 2021 17:26:49 -0700

In response to 

> A new IETF WG has been proposed in the Applications and Real-Time 
> Area. The IESG has not made any determination yet. The following draft 
> charter was submitted, and is provided for informational purposes 
> only. Please send your comments to the IESG mailing list ([email-masked])
by 2021-07-12.

I replied

> > https://www.ietf.org/archive/id/draft-masinter-mime-web-info-02.txt
 
To which Ned responded

> There's a lot here, but the only thing that seems relevant to this effort
is....

So to be clear, I meant to suggest that the scope of work be expanded to
cover reviewing that document and seeing if there is consensus that other
problems identified no longer need solving.

Similarly, what I was suggesting
> > although they haven't taken up my suggestion. Perhaps mediaman could

The "review" might involve reviewing the relative merits of WPACK,
multipart, ZIP, DARE
And perhaps a BCP or standards work to enhance interoperability of systems
that are forced to implement multiple tagging and bagging standards.

> seems to have won that battle.

It's not an explicit battle and it will unlikely be "won".   If this is a
proposal to
reexamine MIME assumptions N years later, I meant to call for some
broadening
of scope to be investigated by the (proposed) working group.