Re: [dispatch] Murray Kucherawy's No Objection on draft-ietf-dispatch-javascript-mjs-13: (with COMMENT)

[Mathias Bynens <[e-mail]>]

On Tue, Jan 11, 2022 at 11:32 PM Ned Freed <[e-mail]> wrote:

> In regards to all these obsolete registrations and x- registrtions
> in particular...
>
> > > What I've observed is that the current media type registry does not at
> > > present contain any of the "x-" media types this document is
> registering.
> > > I believe that makes them new registrations, and so I suggest that
> there
> > > should be text explaining why BCP 178 doesn't apply here.
> > >
>
> > Thank you. Please take a look at this patch:
> > https://github.com/linuxwolf/bmeck-ids/pull/65/files
>
> > For context, these are historical legacy types that are supported in
> > practice: https://mathiasbynens.be/demo/javascript-mime-type Although
> they
> > are OBSOLETED, it’s important that the document specifies them because
> they
> > are required for Web compatibility.
>
> There seems to be considerable misunderstanding about the rules regarding
> obsolete type names, unfaceted types, and type names beginning with "X-".
>
> First, RFC 6838 eliminated the special status of type names beginning with
> "X-". So nothing prevents you from registering type names beginning with
> "X-" as long as the registration is in the standards tree. Appendix A
> of RFC 6838 only applies if the type is being registered in, say, the
> vendor
> tree, which AFAICT is not the case here.
>
> Of course the fact that you can register names beginning with "X-" doesn't
> mean you should. So if you're doing this, a note explaining why ths makes
> sense would be a good idea.
>
> However, the better question is why are all these obsolete type names
> being registered separately. RFC 6838 section 4.2.9 explains the proper
> way to handle old names for the same media type, and the registration
> form now contains a field for listing all of these names.
>
> If you're going to register a bunch of separate types for a bunch of
> similar things, you need to explain why you're doing things this way,
> and more importantly, why they warrant having different names.
>
> And since in this case all of these additional registrations are marked
> as obsolete, I fail to see why they aren't being handle as deprecated
> aliases.
> Or, to pur this another way, why not simply list all 15 (!) aliases in the
> registration for text/javascript and get rid of section 6.2 entirely?
>

Thanks for the pointer to RFC 6838 section 4.2.9, and for suggesting such
an elegant solution. I’ve prepared a patch at
https://github.com/linuxwolf/bmeck-ids/pull/66 that reduces the draft down
to just two registrations, each with a set of aliases:

   - Under “Common JavaScript Media Types”: text/javascript and its aliases
   with file extensions .js and .mjs
   - Under “Historic JavaScript Media Types”: text/ecmascript and its
   aliases with file extensions .es and .mjs

To make it just one registration and remove section 6.2 entirely, we’d need
to list something like “Deprecated file extension(s): .es” alongside “File
extension(s)”, but I don’t see anything in RFC 6838 that would allow this,
and then we’d also be incorrectly listing .es as a legacy extension for the
common types which never had that extension in their registration. Given
that, I think the current patch is as good as it can get. Please take a
look.