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

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

Revised based on feedback.  If we're good to go here, I can put it on the
next review cycle.

-MSK

Media Type Maintenance (“MEDIAMAN”) Working Group Charter [DRAFT v2]

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


   -

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

   Consider any issues around media types for programming languages.
   -

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

   Review the format of the media types registry itself.
   -

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

   Investigate the possibility of using GitHub as both a registration
   interface and a queue for managing the processing of requests, based on the
   model used for link relations and well-known URIs (
   https://github.com/protocol-registries/link-relations and
   https://github.com/protocol-registries/well-known-uris respectively).


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) based on the last work item
   listed above, if needed.


On Sat, May 15, 2021 at 9:41 PM Mark Nottingham <[e-mail]> wrote:

> 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 <[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.
> >
> >> -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)
> >
> > _______________________________________________
> > dispatch mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dispatch
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>