Media Type Maintenance (mediaman)
|WG||Name||Media Type Maintenance|
|Area||Applications and Real-Time Area (art)|
|Personnel||Chair||Harald T. Alvestrand|
|Area Director||Murray Kucherawy|
|Jabber chat||Room address||xmpp:email@example.com?join|
Charter for Working Group
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 and data definition languages such as YANG.
* 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.
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.