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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Jul 2021 01:54:00 -0700

On Wed, Jun 30, 2021 at 9:24 AM Alexey Melnikov <[email-masked]>
wrote:

> Hi all,
>
> On Tue, Jun 22, 2021, at 11:36 PM, Murray S. Kucherawy wrote:
>
> 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.
>
> 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.
>
>
> 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.
>

It's in an internal review state now before being sent out for wider
review, so there's time to make that sort of a change unless there's some
kind of objection from the community.  I interpret Ned's earlier objections
to touching RFC 6838 as being specific to the issue of top level media
types, but you're talking about something else here.  Hopefully he can
confirm (or correct) my understanding.

-MSK

---

From: Ned Freed <[email-masked]>
Date: Thu, 01 Jul 2021 05:54:18 -0700 (PDT)

> > reopen RFC6838, but a separate draft that updates it would be great.

IMO a separate draft discussing additinal information would be the way
to go, assuming a separate draft is even needed. A quick check of the
form shows an OID field that isn't in RFC 6838. Additionally, RFC 6838
says to include the information "if available". I think an argument can
be made that Mac file type/creator codes are never available, so why
bother asing for them?

> confirm (or correct) my understanding.

Speaking as a reviwer, the only additional information that's proved to be
difficult to deal with on occasions is magic numbers. It would be very helpful
to have some guidance as to how to specify them. The form of such guidance
doesn't really matter to me: A note to IANA, draft, whatever.

In any case, a work item to discuss what additional information to add/delete
would be  fine with me.

				Ned