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

[Mark Nottingham <[e-mail]>]

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/