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

["Martin J. Dürst" <[e-mail]>]

Hello Ned, Murray, others,

On 2021-05-13 03:53, Ned Freed 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.

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.


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

Agree with Ned here.

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

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


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

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 [e-mail], 
because some people interested in this work may be on that list but not 
(yet) on the dispatch list.

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

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.

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

I agree with Ned.

Regards,   Martin.

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