Re: [dispatch] [media-types] 3rd WGLC - draft-ietf-dispatch-javascript-mjs - deadline 10th May

[John C Klensin <[e-mail]>]

--On Wednesday, May 19, 2021 12:44 -0400 John Levine
<[e-mail]> wrote:

> It appears that Martin J. Dürst <[e-mail]> said:
>>> Note that this language is not new to this draft; it's
>>> inherited from RFC4329 which this document supersedes.
>> 
>> It is indeed somewhat difficult to understand for people who
>> are not  familiar with the BOM, and autodetection proceedures.
>> 
>> I'd suggest changing:
>> 
>> If this step determines the character
>> encoding scheme, the octet sequence representing the Unicode
>> encoding form signature MUST be ignored when decoding the
>> binary source text.
>> 
>> to something such as:
>> 
>> If this step determines the character
>> encoding scheme, the octet sequence representing the Unicode
>> encoding form signature is not part of the actually decoded
>> binary source text.
> 
> While I agree with your concern, and have given up trying to
> figure out how the Javascript world got so broken that it
> cannot keep its encodings straight without having to sniff the
> contents of every message, I don't think we should change the
> language. It's been there for a long time, everyone wno needs
> to understand it knows what it means, and if we change it,
> we'll be in for a round of "why did they change it and what do
> I have to do different."

John,

While I mostly agree -- Martin is right, but it is not clear
whether making this correct would cause more harm by creating
confusion than it would be worth -- there is a third (and more
drastic) way to look at this.  Content-sniffing and heuristics,
rather than properly marking up text and strict observance of
media types, ultimately just lead to other problems down the
line.  The specifics are different, but a review of why we wrote
RFC 6082, deprecating the Unicode language tagging of RFC 2482,
is relevant here.  Sniffing, simplistic tagging, and so on do
not work reliably unless assumptions are made about assorted
external details and those assumptions are actually correct.
The crude example in this case is that sniffing for Unicode
encoding types works if the underlying CCS is guaranteed to be
Unicode.  If it is something else, all bets are off.

I could make comments about brokenness even stronger than yours
about the choice of file name extensions to determine details of
data types.  I thought the Internet community gave up on that
decades ago.

I've been trying to ignore this thread, but this exchange is
sort of a last straw and it seems it is time to raise more basic
questions.

So some suggestions wrt this document if it is really to go
forward in the IETF:

(1) Martin's suggestion or something like it is an improvement,
but the reason for the change should be clearly explained.  The
style of explanations in Appendix B, many of which are of the
form "We changed X" or "Updated Y to make it better" are
inadequate in that regard without an explanation as to why
and/or the implications of the change.  Otherwise, while some
are more obvious than others, many of them have the potential to
create the type of confusion you identify.

(2) To be clear, similar comments apply to almost every bullet
point in Appendix B: the changes require explanation.

(3) If this document, as suggested by both discussions in this
thread and the "... updates ... to reflect existing usage on the
Internet" introductory text is apparently the result of IETF's
opinion of actual practice in the javascript community, practice
that has diverged enough from what RFC 4329 specified to justify
such a revision.  As an Informational spec expressing our
summary of what is happening elsewhere and clearly not under our
control, the use of normative BCP 14 language is entirely
inappropriate both conceptually and because the very need for
the document is evidence that the relevant implementation and
operational communities are not paying attention.  Phrases like
"MUST foo" should be replaced by ones more like (relying on RFC
8174) "you must do X because anything else will lead to <bad
thing>".

And, if that is too much work or this is the opinion of the
authors or the javascript community about common practdice and
not the IETF, then I recommend either of two other options:

(i) Rewrite the introductory material to indicate that it is the
opinion of the authors and anything they cite.  Then Dispatch
this to the tender mercies of the ISE because, if the IETF can
merely report on actions of others rather than influencing
results, that is not a useful business for us to be in.  If the
IESG then wants to obsolete 4329 and point to the new document
for explanation, nothing prevents that, especially given that
both would be Informational rather than standards track.

or

(ii) Let ECMA/TC39 adopt this document, review, and publish it
as part of the ECMAScript collection.  Then produce a very short
RFC that obsoletes 4329, points to the ECMA document, and adds
whatever information about the reasons for the change seem
helpful.

Grump.
    john