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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 2 Jun 2021 20:56:07 -0700

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 <[email-masked]> 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 <[email-masked]> 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dispatch
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>

---

From: [email-masked]
Date: Thu, 03 Jun 2021 07:25:41 -0700 (PDT)

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

Better, but still some issues. My significant concerns are:

(1) This doesn't prioritize the haptics work. (But if it's the consensus is not
    to do that so be it.)

(2) Unnecessarily reopening RFC 6838.

Details comments below.

> Registration of new media types is defined by BCP 13, which was last

"The IETF" -> "The IANA"?

Based on the degree of urgency I've seen expressed in various comments, I'd
recommend reordering this to haptics, then suffixes, then sec-cons checklist,
then programming languages, then registry format, and finally github.

List order is important even when the text doesn't require item ordering
by the WG.

>    https://github.com/protocol-registries/well-known-uris respectively).

While I don't have a problem with doing this if IANA doesn't, and if it makes
things easier for IANA so much the better, I am dubious that this actually
solves the problems people have with registering media types.

The complaints I've heard about the media type registration process concern the
lack of guidance as to how to fill in the various fields. I took a look at the
two examples, and I don't see how using what appears to be a completely free
form interface will address that.

At a minimum some justification needs to be given as to why this approach
will be an improvement.

>    draft-muthusamy-dispatch-haptics

Shouldn't draft-w3cdidwg-media-types-with-multiple-suffixes also
be listed here?

>    RFC6838bis to the IESG for approval (BCP) based on the last work item

Nothing in RFC 6838 assumes a particular approach to providing the necessary
information to specify a new media type. If github replaces the existing form I
would hope that the existing form address could be changed to redirect to 
Github, but having it display a note with the new URL is always a possibility.

Bottom line: I see no reason why a RFC 6838 bis should be needed here, and
if it is, I think that indicates a change in scope that will need to be
evaluated in its own right.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 3 Jun 2021 08:21:55 -0700

> (1) This doesn't prioritize the haptics work. (But if it's the consensus

It's the first thing on the list.  I can't move it up any higher.

Would you suggest doing not only that, but explicitly saying nothing else
can be done until this ships?

[...]
> "The IETF" -> "The IANA"?

OK.

> then programming languages, then registry format, and finally github.

Upthread you said:

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

...hence the current ordering.  I'll change it to this new ordering and see
how we all like it.

While I don't have a problem with doing this if IANA doesn't, and if it
> makes

There were two proponents for adding this to the charter, so I'll let them
pipe up here.

> be listed here?

Sure, I just wasn't aware of its existence.  I'll add it.

> evaluated in its own right.

I'll remove it as a milestone in the charter.  If it ends up being
appropriate, we can always recharter or at least re-add the milestone.

I've now added this to the datatracker:
https://datatracker.ietf.org/doc/charter-ietf-mediaman/

-MSK

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Jun 2021 13:45:59 -0400

--On Thursday, June 3, 2021 08:21 -0700 "Murray S. Kucherawy"
<[email-masked]> wrote:

>> > Revised based on feedback.  If we're good to go here, I can
>> > put it on the next review cycle.
>> 
 
> Would you suggest doing not only that, but explicitly saying
> nothing else can be done until this ships?
>...

I was about to make exactly the opposite argument.  

Stepping back a few paces...

(1) I believe that, at the time 6838 and it predecessors were
written, there was a shared assumption that proliferation of
top-level media types was not a good idea.  The several rounds
of discussion around haptics lead me to believe that assumption
is now less generally shared and 

 * that people who want top-level types, even if only
	because it makes them feel their work is important,
	should be able to have them and/or 
 * that the argument that, if we don't allow people to
	register whatever they want, they will just squat on the
	names, causing potential uniqueness problems 

should prevail over more subtle considerations and tradeoffs.
While haptics might well be appropriate as a top-level type
under any criteria we might come up with, it seems that a key
part of the work of the proposed WG is necessarily a review of
those criteria (both explicit and oral tradition) and
determining whether revisions or more explicit specifications
are needed.  Approving haptics as a top-level type and only then
doing that review seems wholly inappropriate if only because
haptics would presumably then be a precedent to be considered.

(2) The main argument for putting haptics first in spite of the
above is that doing so is a matter of urgency because of the
interactions with pending ISO action.  That argument might have
been reasonable a couple of years ago, but is now OBE: the ISO
actions and decisions are essentially set in stone and the
window for IETF action having any effect on them has closed.  If
there are any substantive interactions left, we are playing
catch-up.  The squatting we would normally like to avoid has
already occurred.  While it would be better to catch up sooner
rather than later, it is hard to believe that several months one
way or the other will make any difference.  Because a media type
name structure has apparently already appeared in the ISO
documents, we may have no choice other than to approve the
registration.  However, it still makes a difference whether we
approve it as consistent with the policies we are developing or
as an exception based on use and standardization elsewhere.

So, to me. it needs to be "criteria review first, then specific
cases, haptics included" not "haptics first and above all".

Additional observation, which I have said before: if getting
haptics registered is really of very high priority and the ISO
work that would, in a better world, reference it, is, as we have
been told, past the point where it can be changed, then my
understanding of Section 3.1, option 2 of RFC 6838 allows a
procedure that could be _very_ fast:

  (Step 1): If it has not already done so, IESG identifies the
relevant ISO TC as a "recognized standards body".  It is has
already so identified all of ISO that way, this step is a no-op.
  (Step 2): The ISO TC or ISO/CS point to a specification (which
need not be an RFC or I-D leading to on) and asks up to register
the thing.
  (Step 3): The expert review process and/or IANA get to dicker
with the ISO body about the adequacy of the specification if
they conclude that is necessary.

No WG required to address that particular registration (nor the
time needed to set one up and have it reach decisions).  So, to
me, there are only two cases.  Either this is urgent and ISO
wants it or it doesn't.  In the latter case, I don't see the
case for urgency rather than due process and consideration by a
WG.

 best,
   john

    john

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 Jun 2021 14:30:53 +1000

On 4 Jun 2021, at 1:21 am, Murray S. Kucherawy <[email-masked]> wrote:
> There were two proponents for adding this to the charter, so I'll let them pipe up here.

The interfaces aren't freeform; if you create an issue, you'll see it uses a template to fill out. Furthermore, the README of each repo provides guidance.

Stepping back, though, I think the bigger question here is whether the registry policies are still fit for purpose. Right now, a URI scheme can be registered provisionally on a FCFS basis, and those schemes are not syntactically distinguished from permanent schemes. OTOH, media types do syntactically distinguish standards-track registrations from others, and places several additional hurdles in the place of those registrations (which by far are the most desirable).

This difference in policies is strikingly odd, and seemingly arbitrary. It would be good to understand why there is a difference, and whether it's still justifiable. 

If the community comes to an understanding that the barriers to registration are appropriate, the current procedures are likely adequate (although it'd be good to get feedback from other standards bodies). However, if they're to be changed, the registration procedure would need consideration too.

With that in mind, I suggest replacing the bullet about GitHub with:

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

Cheers,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 13 Jun 2021 23:47:17 -0700

On Mon, Jun 7, 2021 at 9:31 PM Mark Nottingham <[email-masked]> wrote:

> If the community comes to an understanding that the barriers to
> registration are appropriate, the current procedures are likely adequate
> (although it'd be good to get feedback from other standards bodies).
> However, if they're to be changed, the registration procedure would need
> consideration too.
>
> * Evaluate the registry policies and procedures in the context of how
> media types are currently used, and modify them if necessary.
>

I've folded this suggestion and John's into the draft charter, which I've
now added to the datatracker so that people can see changes over time as we
iterate:

Please have a look and let me know if this is good enough to proceed to the
formal part of chartering.  Note that the process still requires two review
passes through the IESG and one formal round of public commentary, so I'm
wondering if people feel like it might be close enough to start those
processes, or if we should iterate here again first.

I've also, per John's suggestion, inquired about whether ISO generally, or
a TC specific to haptics, is already listed as an approved SDO for media
type registrations.   Even if they are, though, BCP 13 still requires a
standards track RFC for a top-level registration, though the path he
proposes would be fine for all the sub-registrations they might want to
make.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 16 Jun 2021 12:49:06 -0700

On Sun, Jun 13, 2021 at 11:47 PM Murray S. Kucherawy <[email-masked]>
wrote:

> Please have a look and let me know if this is good enough to proceed to
> the formal part of chartering.  Note that the process still requires two
> review passes through the IESG and one formal round of public commentary,
> so I'm wondering if people feel like it might be close enough to start
> those processes, or if we should iterate here again first.
>

(Adding the "[email-masked]" list, so people there can comment if
needed before I start the process)

An additional question: Would it be better to use the existing media types
IETF list for this work, or should it get a separate mailing list?

-MSK

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 17 Jun 2021 09:29:36 +0900

> IETF list for this work, or should it get a separate mailing list?

I think using the existing list would be preferable. It's currently very 
low traffic, but should have a number of people on it that can 
contribute, even if just by checking that they are fine with where 
things are going and therefore not raising any comments.

Regards,   Martin.

---

From: "Paul Libbrecht" <[email-masked]>
Date: Thu, 17 Jun 2021 08:00:29 +0200

Hello list,

It’s interesting to see a renovation wind about the registration 
process and details.

I am wondering if the group is the right place to prepare an update of 
the registration template so as remove the Macintosh 4-letter-codes and 
insert clipboard flavours for windows and universal type identifiers for 
macOS.

This was discussed a few times on this mailing list.
I have been in contact with a few media-type proposers, some of which 
have accepted a change of their declaration in this direction.
I have been in contact with one IETF-aware person to update RFC6838 but 
that has not progressed.

Thanks in advance.

Paul

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 22 Jun 2021 15:36:41 -0700

On Wed, Jun 16, 2021 at 11:00 PM Paul Libbrecht <[email-masked]> wrote:

> I am wondering if the group is the right place to prepare an update of the
> registration template so as remove the Macintosh 4-letter-codes and insert
> clipboard flavours for windows and universal type identifiers for macOS.
>
> I have been in contact with a few media-type proposers, some of which have
> accepted a change of their declaration in this direction.

There's been no feedback from anyone else, up or down, about this idea.  My
own impression is that this isn't quite within scope of what we're talking
about for this effort, but then again it makes sense to include this now
rather than spin up a subsequent effort or wait for the next train.
Naturally I'm happy to include this in the proposed charter if there's
consensus to include it.

I'm just about to enqueue the charter we have in hand for its first IESG
review pass before it goes out for general review.  If this or any other
change should be included in that submission, please (everyone, anyone) say
something sooner rather than later.

-MSK

---

From: "Paul Libbrecht" <[email-masked]>
Date: Wed, 23 Jun 2021 09:00:26 +0200

Hello Murray,

Here are two reasons that I think may be convincing to change the 
template:

- the old Macintosh 4-letter code is long dead
- macOS UTIs are and have always been specified by Apple. Finding 
documentation on them is often a sport. As far one could see until 2010: 
no more registration, applications are free to register UTIs. As a side 
effect of the proprietary nature, it appears that around 2010 Apple 
started to indicate that the `public` subtree of the UTIs is reserved to 
types declared by Apple. Other documentation pages still do not mention 
this. As a result… Some UTI declarations (e.g. in use in widespread 
desktop apps) thus have become invalid. The media-type inclusion of UTIs 
can help against this unpredictability.

You are right that clipboard types tend not to be a super-fashionable 
topic and I find it rather good that this does not trigger a flood of 
mails such as the discussion on the necessity of a new prefix.

Thanks in advance.

Paul

On 23 Jun 2021, at 0:36, Murray S. Kucherawy wrote:

>> have

---

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 30 Jun 2021 17:24:21 +0100

Hi all,

On Tue, Jun 22, 2021, at 11:36 PM, Murray S. Kucherawy wrote:
>> __
>> I am wondering if the group is the right place to prepare an update of the registration template so as remove the Macintosh 4-letter-codes and insert clipboard flavours for windows and universal type identifiers for macOS. 
>> 
>> I have been in contact with a few media-type proposers, some of which have accepted a change of their declaration in this direction. 
>> I have been in contact with one IETF-aware person to update RFC6838 but that has not progressed.
>> 

I am the guilty IETF-aware person...

I am thinking that if we are doing all other related work we might as well tackle this, so I am in support of doing this in the WG. Now ideally I would like this to be addressed as an extension to the media type registration template that list extra optional fields. So I don't want to reopen RFC6838, but a separate draft that updates it would be great.

> 
> There's been no feedback from anyone else, up or down, about this idea.  My own impression is that this isn't quite within scope of what we're talking about for this effort, but then again it makes sense to include this now rather than spin up a subsequent effort or wait for the next train.  Naturally I'm happy to include this in the proposed charter if there's consensus to include it.
> 
> I'm just about to enqueue the charter we have in hand for its first IESG review pass before it goes out for general review.  If this or any other change should be included in that submission, please (everyone, anyone) say something sooner rather than later.
Hopefully it is not too late :-).

Best Regards,
Alexey

---

From: "Paul Libbrecht" <[email-masked]>
Date: Wed, 30 Jun 2021 23:09:36 +0200

I am happy to help on this topic if this is feasible.
paul

On 30 Jun 2021, at 18:24, Alexey Melnikov wrote:

>>> I am wondering if the group is the right place to prepare an update 
>>> of the registration template so as remove the Macintosh 
>>> 4-letter-codes and insert clipboard flavours for windows and 
>>> universal type identifiers for macOS.
>>>
>>> I have been in contact with a few media-type proposers, some of 
>>> which have accepted a change of their declaration in this direction.
> I am thinking that if we are doing all other related work we might as 
> well tackle this, so I am in support of doing this in the WG. Now 
> ideally I would like this to be addressed as an extension to the media 
> type registration template that list extra optional fields. So I don't 
> want to reopen RFC6838, but a separate draft that updates it would be 
> great.
>
>>
>> There's been no feedback from anyone else, up or down, about this 
>> idea.  My own impression is that this isn't quite within scope of 
>> what we're talking about for this effort, but then again it makes 
>> sense to include this now rather than spin up a subsequent effort or 
>> wait for the next train.  Naturally I'm happy to include this in the 
>> proposed charter if there's consensus to include it.
>>
>> I'm just about to enqueue the charter we have in hand for its first 
>> IESG review pass before it goes out for general review.  If this or 
>> any other change should be included in that submission, please 
>> (everyone, anyone) say something sooner rather than later.