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

["Martin J. Dürst" <[e-mail]>]

Hello Bradley,

On 2021-05-20 08:06, Bradley Farias wrote:
> I also would like to speak somewhat directly.
> 
>> I am also suggesting that if we, the IETF, say that someone MUST
>> do something in a particular way, and do so with the full
>> knowledge that the community to whom that is being addressed has
>> ignored us before and may ignore us again, it is bad for the
>> IETF's reputation... and just silly.
> 
> I would state that given the sheer denialism and duration of this review
> for this particular RFC the reputation is already been soured for both
> parts of the Node.js community and ECMA TC39 members. I've become fairly
> used to 6 months of silence, followed by a brief comment period resetting
> the 6 month time for comments that is both derisive and often demanding
> re-explanation of how the browsers and the current state of web works. This
> is not a good look and it does feel that the IETF largely does already
> ignore other ecosystems, so it is understandable that they reciprocate in
> kind even if that is undesirable for all parties involved.

Just one point that looks like a potential very deep and decisive 
misunderstanding. There is absolutely no "6 month comment period" in the 
IETF. In my 25 years of being involved in the IETF, this is the first 
time I have head of a "6 month comment period". The longest comment 
period that I can remember having heard of up to now is 6 weeks (4 weeks 
IETF-wide non-WG last call + two weeks extra over Christmas). If you 
could tell us how/where you learned about such a (nonexisting!) concept, 
that might help us find and fix a problem.

My (wild?) guess is that the six months might come from the sentence
"Internet-Drafts are draft documents valid for a maximum of six months"
which is included in every Internet draft. But please note the word 
"maximum". These six months are there to make sure people don't feel 
satisfied at leaving something as an Internet Draft forever; the only 
choices are 1) abandon, 2) resubmit an update, and 3) move on to RFC.

But it's perfectly fine (indeed, highly desirable and recommended) to 
move at a faster pace. It's not unseen that somebody submits a draft and 
then a few minutes later submits a new version just because they have 
found another typo. For an extreme example of "submit early and often", 
please see 
https://datatracker.ietf.org/doc/html/draft-hixie-thewebsocketprotocol-76 (76 
drafts over 17 months).

So in order to push your work forward, I recommend you wait until the 
discussion has died down, incorporate the necessary changes, and 
resubmit a draft. Then you ask people to check the changes, and repeat 
as necessary. Once things have cooled down, you contact the responsible 
WG chair (or AD) and tell them that you think the document may be ready 
for the next step such as WG last call (which may include more comments 
and more drafts).

Finally, some comments closer to the subject matter. I think John Levine 
is correct that the wording change I proposed may be misinterpreted as a 
material change. John Klensin showed how that can be dealt with.

With regards to claims that the JavaScript community didn't follow the 
first RFC to the letter: I think everybody who has been doing standards 
work, and that should include most people in the IETF, know an example 
or two (or many more) where well-intended specification language didn't 
work out in practice, and the language (and not the practice) were 
fixed. The formal explanation is "dynamic interaction of diverse players 
in a complex ecosystem" or some such. Stuff happens. There is no 
protocol police, but there's paper (or electrons) to document things and 
bring everybody on the same page.

Regards,   Martin.


>>   While I suggest that cleaning up the
> language to make it more precise from a technical standpoint, I
> don't feel very strongly about that, especially if you and
> others are convinced that no one outside the current javascript
> implementation community will ever read it.   But I do think it
> is important to remove the BCP 14 normative language and to
> improve the quality of explanation of changes, even if to more
> clearly say "we said to do X, the consensus of common practice
> has chosen Y instead, so, because this is an Informational and
> descriptive document, we are now specifying Y without expressing
> any opinion of which choice would be better in some different
> reality."
> 
> I think such is possible, but given the lack of communication after such
> changes we have done in the past I do not see it as a fruitful exercise
> except to gain a new 6 month comment period followed by silence and a last
> minute issues on what I personally regard somewhat as repetitive nature
> that mostly are resolved by non-significant changes and or relying on
> explanation of how other standards have evolved outside of the IETF
> process, likely in part due to this friction.
> 
>> If "the javascript crowd" is opposed to our doing that much,
> then this ought to be a document that they publish in some
> appropriate place where IETF consensus is not needed, and that
> the IETF, if appropriate, should just reference it.
> 
> This is the kind of derision I was referencing earlier.
> 
> On Wed, May 19, 2021 at 5:38 PM Myles Borins <mylesborins=
> [e-mail]> wrote:
> 
>> To speak candidly... I don't love the us vs. them language being thrown
>> around here.
>>
>> There are many people who do work with and on JavaScript that participate
>> within IETF, and drawing a distinction between the two parties seems
>> unnecessarily decisive.
>>
>> Myself and various others have been trying, as good citziens of the
>> internet, to document a web reality and update the current out of date RFC
>> in order to make the internet better. I outlined examples above of certain
>> platforms waiting on a clear signal from IETF / IANA before supporting the
>> .mjs extension with the appropriate mimetype... The lack of this support
>> creates developer friction and confusion.
>>
>> It is extremely demotivating to be trying to work through a process for
>> many years and to consistently have folks jump in to give minor feedback
>> that continues to derail progress and burn out the people trying in good
>> faith to work with the IETF and hopefully become more regular contributors.
>>
>> An expression comes to mind that "perfect is the enemy of good". This is
>> not to say that we should lower the quality bar here, but the current RFC
>> is inaccurate to web reality in ways this new rfc attempts to fix.
>>
>> We first attempted to amend the existing rfc, but were requested to make a
>> new rfc due to the level of changes. We are now finally what feels like
>> close to done and are being challenged on both parts of the RFC we never
>> wrote as well as the fundamental existence of the document to begin with.
>>
>> I understand that folks come and go and that there are many steps along
>> the way... but the way this overall process has played out is extremely
>> demotivating and disappointing.
>>
>> I will definitely keep trying to push this forward, put I do wonder if we
>> could table some of the feedback we are receiving right now to come in an
>> update to the proposed text... As I genuinely fear that this will never get
>> published at the rate things have gone for over 3 years now
>>
>> On Wed, May 19, 2021, 6:20 PM John C Klensin <[e-mail]> wrote:
>>
>>>
>>>
>>> --On Wednesday, May 19, 2021 15:10 -0400 John R Levine
>>> <[e-mail]> wrote:
>>>
>>>>> 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. ...
>>>>
>>>> We went through all these arguments a couple of months ago and
>>>> the Javscript crowd made it crystal clear that the current
>>>> awful behavior is built into vast amounts of software,
>>>> starting with all of the web browsers on your phone and your
>>>> computers, and it's not going to change.
>>>
>>> Understood and no disagreement.  Nor am I suggesting that the
>>> IETF should say "change it anyway" or anything equally unlikely
>>> to result in changed behavior.
>>>
>>>> While I am no happier than you are that we got to this point,
>>>> I don't think that a pissing contest would do anyone any good.
>>>> I suppose we could add a note saying something like the media
>>>> sniffing is a concession to widespread existing practice and
>>>> isn't intended to be a precedent for any new media types.
>>>
>>> Nor was I suggesting a pissing contest.  I am suggesting that
>>> whether to publish a document in the IETF Stream is an IETF
>>> decision, made at the IETF's discretion, and that the IESG has
>>> told us that any such documents must represent IETF consensus.
>>>
>>> I am also suggesting that if we, the IETF, say that someone MUST
>>> do something in a particular way, and do so with the full
>>> knowledge that the community to whom that is being addressed has
>>> ignored us before and may ignore us again, it is bad for the
>>> IETF's reputation... and just silly.
>>>
>>> So I am not suggesting any changes in what the document
>>> describes and recommends.  While I suggest that cleaning up the
>>> language to make it more precise from a technical standpoint, I
>>> don't feel very strongly about that, especially if you and
>>> others are convinced that no one outside the current javascript
>>> implementation community will ever read it.   But I do think it
>>> is important to remove the BCP 14 normative language and to
>>> improve the quality of explanation of changes, even if to more
>>> clearly say "we said to do X, the consensus of common practice
>>> has chosen Y instead, so, because this is an Informational and
>>> descriptive document, we are now specifying Y without expressing
>>> any opinion of which choice would be better in some different
>>> reality."
>>>
>>> If "the javascript crowd" is opposed to our doing that much,
>>> then this ought to be a document that they publish in some
>>> appropriate place where IETF consensus is not needed, and that
>>> the IETF, if appropriate, should just reference it.
>>>
>>> best,
>>>     john