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

[Mathias Bynens <[e-mail]>]

On Sun, Jan 9, 2022 at 2:37 AM Murray S. Kucherawy <[e-mail]>
wrote:

> On Fri, Jan 7, 2022 at 1:20 AM Mathias Bynens <[e-mail]> wrote:
>
>>
>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> The MUST in Section 2 is kind of peculiar.  Is it a reminder to
>>> implementers
>>> today that they need to keep an eye out for possible updates in the
>>> future?  If
>>> so, I think it's unnecessary.  If something else is meant, then I'm quite
>>> confused.
>>>
>>
>> It captures the fact that ECMAScript is a living standard that keeps
>> evolving, with new versions being published annually. It is possible that a
>> new script goal (other than "classic script" and "module") is added in the
>> future, and at that point, we might need a new RFC with updated media type
>> registrations.
>>
>
> I think what you've written here is much more clear language than what's
> in the document presently.
>
> When I see a MUST or SHOULD, I'm expecting to see requirements related to
> interoperability or security of the protocol itself, or operational
> configuration of a component that implements it.  Thus, I don't think this
> use of MUST is appropriate.
>
>
>>
>>> This document is registering media subtypes starting with "x-" even
>>> though BCP
>>> 178 says not to do that.  If the working group intends to do this for
>>> historical reasons, I suggest including a sentence explaining that this
>>> is
>>> being done intentionally, perhaps under Appendix A of RFC 6838.  (See,
>>> for
>>> example, Section 6 of RFC 8894.)
>>>
>>
>> This is not new content / a new registration, but rather content
>> inherited from RFC4329, which our draft iaims to supersede. The draft
>> already explains that it updates RFC4329. Is that sufficient?
>>
>
> 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.