Re: [I18ndir] Review volunteer needed (Fwd: [dispatch] WGLC of draft-ietf-dispatch-javascript-mjs-07)

[Patrik Fältström <[e-mail]>]

On 29 Apr 2020, at 3:41, John C Klensin wrote:

> Since some hours have gone by without a response to your message and I was in need of an excuse to delay getting to an unpleasant task...

Now I have read the draft as well.

> Moreover, if I correctly understand what seems like unnecessary convoluted text (in both versions) a BOM is ignored in further processing if the character encoding scheme is determined to be UTF-8 in 4.2(2) or 4.2(3) but not ignored if charset="UTF-8" is present and the BOM occurs anyway (something clearly allowed by RFC 3629).  That doesn't appear to make sense.

I think I see the same thing as you, which is that even if the charset parameter states the encoding is UTF-8, if the data itself starts with a BOM, then the text is to be treated as UTF-16.

That is just so wrong.

I went to the ECMA spec and see they use UTF-16 all over the place, and have to bend over backwards to get things right. It feels like reading a BER encoding spec (again). :-)

This "problem" do already exist in RFC 4329...

But, if they update RFC 4329 I think they should clean this up, and my suggestion would be:

The encoding must be what is actually labeled. If the encoding is UTF-16 (which it seems it often is), then it should be tagged as UTF-16, not UTF-8 with BOM.

   Patrik

> If it was
> intended, enough of an explanation would be in order that the reader does not concluded it is just a mistake in the document (I notice the I-D already corrected a mistake in 4329).  So, having spent five minutes with 4329 and the diff and another five writing this note, I can say with some confidence that the I-D needs work and that someone is going to need to work with the document authors to explain the issues, some of which are substantive, not just text in need of tuning, and sort things out.   You may be looking for a volunteer to do that job, not just an early reviewer.
>
> Back to lurking.
>     john
>
>
>
>
> --On Tuesday, April 28, 2020 14:14 -0500 Pete Resnick
> <[e-mail]> wrote:
>
>> Folks,
>>
>> DISPATCH has made a working group last call on
>> draft-ietf-dispatch-javascript-mjs. Given how much i18n
>> content there is, the ADs and chairs agreed that an early
>> review wouldn't hurt. There is a bunch of text about formal
>> programming languages in this draft, so I didn't want to just
>> stick somebody with it. Anyone feel comfortable enough to take
>> on a review?
>>
>> Note that the review itself is much less horrible than it
>> seems. This is really a -bis draft of RFC 4329, and most of
>> the i18n language in here is unchanged from 4329. See:
>>
>> https://www.ietf.org/rfcdiff?url1=rfc4329&url2=draft-ietf-disp
>> atch-javascript-mjs-07
>>
>> So it's really just reviewing any changes, and making sure
>> that nothing absolutely egregious was in 4329 itself.
>>
>> Thanks,
>>
>> pr
>>
>> Forwarded message:
>>
>>> From: Ben Campbell <[e-mail]>
>>> To: DISPATCH WG <[e-mail]>
>>> Cc: dispatch chairs <[e-mail]>, ART ADs
>>> <[e-mail]>,
>>> [e-mail] Subject:
>>> [dispatch] WGLC of draft-ietf-dispatch-javascript-mjs-07
>>> Date: Thu, 23 Apr 2020 14:24:47 -0500
>>>
>>> Hi,
>>>
>>> This is a repeat working group last call of
>>> draft-ietf-dispatch-javascript-mjs-07.
>>>
>>> https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascri
>>> pt-mjs/
>>>
>>> The new version has changed quite a bit due to feedback from
>>> the first  WGLC, shepherd feedback, and feedback from others.
>>> In particular, this  version obsoletes RFC 4329, rather than
>>> updating as did the version  from the first WGLC.
>>>
>>> This WGLC will end on 8 May 20202. Please send feedback to
>>> the  DISPATCH list and the authors. And if you review the
>>> document and  think it's ready to go, please say so.
>>>
>>> Thanks!
>>>
>>> Ben
>
>
> -- 
> I18ndir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i18ndir