-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
comments on initial draft #1
Comments
@allenwb thanks, incorporated the rewording changes. The draft has also been updated to be more in scope of what @adamroach was expecting. Do you want to propose |
I would be interested to hear from such agents on if they plan to use such a signal. (Or indeed, I would be interested to hear examples of such agents at all.) |
I know there exists various systems that transmit source text over the wire, but am not sure they use MIME. I also don't know of any that support specifying the grammar of a given source text though. All I know of use a single grammar when transmitting source texts. |
@allenwb after some checks. |
@bmeck --
Seems like a chicken-and-egg problem. Adding it here would seem to give those systems that want this level of hinting a means to do so without requiring them to first come up with something proprietary. Leave it out if you're concerned it's going to slow you down unnecessarily, but my personal opinion is that it would be a simple addition in this document to head off the need to make another registry change (in another document) later. |
I generally agree with @adamroach thoughts WRT to |
@allenwb ok, will add. did you want an explicit |
@allenwb is 73780d0 sufficient to close this? I left it open ended in case ECMA-262 ever adds more goals. I could not find a phrasing in ECMA-262 for these "top" level goals except in:
But we might want to rephrase the description somehow that it would be shown to only be script and module for now. |
closing as fixed |
missed #1 (comment) but yes, 73780d0 seems fine. |
Thanks for carrying this torch!
Note throughout that the proper capitalization is ECMAScript not EcmaScript
I'd reference this as:
because the Ecma-262.htm link will always contain information about the most current edition of the standard. Or perhaps use https://www.ecma-international.org/ecma-262/ which should always take you directly to the html version of the most current edition. In general, we want the revised RFC to have an edition-free reference to ECMA-262 which means use the current edition, whatever that might be.
Also note that the official name of the standards organization has been "Ecma International" for quite a few years.
I recommend rewording this so you don't have to reference obsolete versions of ECMA-262. Maybe:
(BTW, it seems to me that this and subsequent material makes a strong argument for the application/javascript+module. If MIME types are supposed to be the mechanism that conveys out-of-band info on how to interpret a document and out-of-band info is needed to choose the correct parsing goal symbol for ECMAScript documents then the MIME type needs to encode that info. The fact that HTML has another mechanism doesn't seem adequate because it doesn't account for non-HTML agents that need to use MIME types to transmit ECMAScript documents).
The text was updated successfully, but these errors were encountered: