03:28
<dean.highpower>
Hello, does anyone know about the "willful violation of RFC 5322" note in section 4.10.5.1.5 Email state of the whatwg HTML spec? The comment raises some concern for me, since RFC-5322 is not the appropriate standard to find the syntax of email addresses as used on the public Internet today to route email. The correct standard is RFC-5321, which defines the SMTP protocol and includes a grammar for Mailbox which is what most people think of as an email address. This is what people sometimes call the "envelope" address. The RFC-5322 document specifies the format of the email message content, not the protocol used to transport mail. So, yeah: you should not follow RFC-5322, but you should follow RFC-5321.
07:40
<annevk>
dean.highpower: there's a long discussion in https://github.com/whatwg/html/issues/4562 without much progress, though someone from the i18n WG might make another attempt this year.
11:27
<judekeyser>

Hello, I badly apologize if the question does not fit this room, but I'm having trouble understanding a piece of JavaScript code and no one could help me in regular javascript servers. The code I'm concerned with is the following (ready to use):

(async () => {
    const stream = (function* chunks(json) {
        const jsonString = JSON.stringify(json);
        const jsonBytes = new TextEncoder().encode(jsonString);
    
        let index = 0;
        while(index < jsonBytes.length) {
            const i = index;
            const j = Math.min(jsonBytes.length, i + 10);
    
            const slice = jsonBytes.slice(i, j);    // LINE (A)
            index = j;
            yield slice;
        }
    })({"Hello!": [2023, 2024 ]});
    
    const jsonBack = await new Response(new ReadableStream({
        type: "bytes",
        start: function(controller) {
            for(const chunk of stream) {
                controller.enqueue(chunk);
            }
            controller.close();
        }
    })).json();
    
    console.log(jsonBack);
})()

this code works as expected (google chrome, firefox; latest versions). However, when I replace in line A, .slice with .subarray, I get different kind of issues, telling me the JSON ends abnormally (in both browsers). I've crawled the official specification of the different API's, and I couldn't find a single clue about whether or not the version with .subarray violates the specification.

For what is worth, turning .json() to .text() confirms that in the .subarray case, only the first chunk seems to be taken into account. I assume (but not sure about it) the same happens for .json().

My question, to make it clear, is: is the current code with .slice already violating a point of the specification; and is the version with .subarray violating it and how? Could it be a browser bug, common to both Firefox and Google Chrome? Many thanks in advance! This issue puzzles me a lot for some days now

14:07
<jub0bs>
Do you mean "reasonable options" for fixing the CORS error? I'm not sure I can think of more than what I've already suggested, tbh. One difficulty is that browsers are often left with insufficient contextual information about a preflight failure to produce a helpful CORS error message. For a typical example, see https://jub0bs.com/posts/2023-02-08-fearless-cors/#9-ease-troubleshooting-by-eschewing-shortcuts-during-preflight
15:11
<judekeyser>

Hello, I badly apologize if the question does not fit this room, but I'm having trouble understanding a piece of JavaScript code and no one could help me in regular javascript servers. The code I'm concerned with is the following (ready to use):

(async () => {
    const stream = (function* chunks(json) {
        const jsonString = JSON.stringify(json);
        const jsonBytes = new TextEncoder().encode(jsonString);
    
        let index = 0;
        while(index < jsonBytes.length) {
            const i = index;
            const j = Math.min(jsonBytes.length, i + 10);
    
            const slice = jsonBytes.slice(i, j);    // LINE (A)
            index = j;
            yield slice;
        }
    })({"Hello!": [2023, 2024 ]});
    
    const jsonBack = await new Response(new ReadableStream({
        type: "bytes",
        start: function(controller) {
            for(const chunk of stream) {
                controller.enqueue(chunk);
            }
            controller.close();
        }
    })).json();
    
    console.log(jsonBack);
})()

this code works as expected (google chrome, firefox; latest versions). However, when I replace in line A, .slice with .subarray, I get different kind of issues, telling me the JSON ends abnormally (in both browsers). I've crawled the official specification of the different API's, and I couldn't find a single clue about whether or not the version with .subarray violates the specification.

For what is worth, turning .json() to .text() confirms that in the .subarray case, only the first chunk seems to be taken into account. I assume (but not sure about it) the same happens for .json().

My question, to make it clear, is: is the current code with .slice already violating a point of the specification; and is the version with .subarray violating it and how? Could it be a browser bug, common to both Firefox and Google Chrome? Many thanks in advance! This issue puzzles me a lot for some days now

okay for what's worth, I understood what happened here. When enqueuing, the buffer is detached. This forces the length to go down to 0, which abruptly terminates my emission loop and I never emit more than 1 chunk, which is the cause of all issues. That's why I don't have the expected TypeError, since actually I never pass a detached buffer, as the loop terminates after.

I must say debugging this was kind of an adventure! Not sure if it's all clear for everyone that enqueue detaches the buffer, while reading the documentation. but I eventually found it, collecting all the pieces together

16:12
<dean.highpower>
That issue is regarding the extension of the Mailbox grammar in RFC-5321 to support Unicode, which is done in RFC-6531, section 3.3 Extended Mailbox Address Syntax. I should note that the analogous extensions of all the the RFC-5322 grammars is done in RFC-6532. So yeah, get the basic US-ASCII syntax right by using the grammar in 5321, then extend for Unicode using 6531.
16:15
<dean.highpower>
The way the JSON Schema Validation standard handles this is to recognize two types: "email" for the US-ASCII style, and "idn-email" for an Mailbox address supporting Unicode.
22:07
<dean.highpower>
annevk: I put in my $0.02 in the github issue. Does anyone take the position that RFC-5322 (+RFC-6532) is the relevant standard for email address syntax? (As implied by the "willful violation" comment?)
22:53
<Tomz_plug>
Hello sorry for bothering Y'all, just wanna find out if anyone interested in cannabis and psychedelics products? I’m a supplier of quality cannabis and psychedelics products like shrooms, DMT, Lsd, Mdma, ketamine, chocolate bars, cart vapes,Clone cards, buds, wax, shatter, Edibles,distillates and some chill pills, Cashapp flip and many more products prescribed for patients as well. Let me know if you’re interested by DMπŸ”₯🍁 see products in our channel πŸ‘‡πŸ‘‡πŸ‘‡πŸ‘‡ https://t.me/hightime_markert