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

[[e-mail]]

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

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.

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

"The IETF" -> "The IANA"?

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


>    -

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.

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

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.

> Input Document(s):

>    -

>    draft-muthusamy-dispatch-haptics

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

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

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