As I understand it, the prophecy is that when the state of Israel is fully unified once more, and the temple of Solomon is rebuilt, Jesus will return and the second battle of Armageddon will commence.

End of the world, rapture of the believers into Heaven, the whole bit.

Essentially. If the end user is being asked to make a financial outlay to get to the same things they did before, it’s unlikely that will go down well.

Excellent. I’m on Stage 4 on the Thursday afternoon: “Brewing Tea Over The Internet”.

Should be fun times, see you there.

I haven’t been exploring in the depths of EFnet in …many years. I’m confined to the programming-related channels I found in the Way Back When, nowadays: at the moment, #c is probably the most active and it’s almost all old-timers.

Did the predilection for tea give me away?

I did go to a conference once where they were handing out laptop stickers, and in the pack was a 418 teapot.

Of course, a week after I stuck that to my machine, it died. Telling the laptop it was a teapot didn’t agree with it, I guess.

For “real” RFCs that aren’t Apr 1st jokes, there’s an independent submissions track for the public to write Internet-Drafts and then submit them into the review process.

With the joke RFCs, they get emailed straight to the editor at least two weeks beforehand. I’m not privy to the selection meeting, but I expect it’s fun.

I never understood the beef people had with that. The Internet is a series of tubes, of various widths and sizes, with inputs at random points in the stream.

Plumbing analogies are apt.

So replicators are kind of a special case: they can make anything already fully prepared, without the need for a brewing command to be sent. It’s possible that by the 24th century, there’s a compatibility layer between Replicator Intermediate Language and HTCPCP, but I’ll leave that to future generations to establish.

Out.

Can’t stand pineapple at the best of times, on pizza is another level of wrong.

The biggest problem IPv6 has is that IPv4 has been so hugely successful: gargantuan resources have been poured into getting the world connected on IPv4, and the routers/etc deployed in the field (especially in sub-Saharan Africa, south Asia, and other places which got the Internet late) are built around version 4: data paths 32 bits wide, ASICs and firmware developed with 4-byte offsets, and so on.

It’s a big effort, and more importantly an expensive effort, to move all that infrastructure over for what the end user perceives as no benefit: their websites load just the same as before.

I quite like the idea of HTTP 256 Binary Data Follows, which is just 200 OK but you asked for a non-text content type file.

I don’t think the extra address space of IPv6 is the problem holding back its adoption, so “IPv4 with another octet” would likely run into the same issues.

Not that it’s a bad idea, it’s just an idea that’s unlikely to catch on.

You’d have to catch up with Mr Masinter to get his opinion on adding error 418, I’m afraid; that piece of the business wasn’t my work.

I’m happy it’s there though: it may have sparked flamewars, but at this point what hasn’t. It does bring somewhat of that sense of humanity to the whole enterprise of working on the Internet.

As it turns out, one of the Apr 1st RFCs for this year covers AI Sarcasm Detection, but I can see more serious protocols arising for the transfer of AI model data and/or training procedures in the coming years.

I’d also hope ActivityPub reaches Internet Standard level, though it may fall outside the IETF’s scope of operations.

As the saying goes, “for bandwidth, nothing beats a truck full of tapes 1TB MicroSDs hurtling down the highway”.

It’s not up to Mr Masinter or myself to police the usage of anything defined in the standard; if people feel like being assholes regarding the issuance of 418 errors, at least they’re being whimsical assholes.

Could be worse; could be 200 with an error message inside, negating the entire point of error codes. I see that all the time.

A little lower down the stack, I always liked the Evil Bit in TCP, a standard which removes all need for firewalls heuristics by requiring malware or packets with evil intent to set the Evil Bit. The receiver can simply drop packets with the Evil Bit set, and thus be entirely safe forever from bad traffic.

At the physical interface layer where data meets real life, I especially enjoy IP over Avian Carrier; that link in particular is to the QoS definition which extends the original spec for carrying packets by carrier pigeon.

For Apr 1st RFCs in particular, the process is that you write your document in conformance to the RFC Editor’s Style Guide and email it to the editor directly. If you have a not-a-joke standard that you’d like to be considered, that’ll go through as an Internet Draft first, and then there are stages of review.

I haven’t been through the latter, but the editors are very approachable over email; I had no issues submitting my RFC for review and revision.

That’s a tough one: most standards are codified as such because they’re already seeing wide use. The major example of one that’s been worked the other way around is IPv6: it’s been a standard for a very long time, and still doesn’t seem to be seeing adoption.

Of course, I wouldn’t say I was bullish on IPv6. 32 bits is enough for anyone, right.