A loosely moderated place to ask open-ended questions
Search asklemmy π
If your post meets the following criteria, it's welcome here!
Looking for support?
Looking for a community?
~Icon~ ~by~ ~@Double_A@discuss.tchncs.de~
I loved sharing this with my senior who hadn't seen it before, and it gave our small team a Ggod chuckle one afternoon. Thanks for your creation.
With the absence of a crystal ball, but with excellent inner knowledge, what future standards could you see being implemented in the next 10 years for internet?
Iβm actually going to that conference! Whatβs the title of your talk? Iβll be sure to attend it!
We're there any early internet standards you were super bullish on at the time that didn't get picked up? In retrospect, if it had been adopted do you think it would have had the impact you were hoping for
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.
You can unilaterally create another status code. What do you create?
Wasn't there a new HTTP action recently proposed for "This is a JSON RPC request that we've convinced ourselves is actually REST and we've been using POST and someone finally pointed out that that was stupid"?
Not a new status code but still vaguely amusing.
A new RFC for IPv7. It's just IPv4 with an extra octet. Yes or no?
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.
Was RFC 7168 written with Captain Picard's tea Earl Gray, hot in mind? If not, are follow up modifications planned?
What's the funniest legitimate non-joke standardization detail you've come across?
Is the internet still kept in Big Ben?
Yes, unless Jen needs to borrow it for a presentation.
The number one question I would ask about HTTP would be: Why was the "Referer" header initially added and why wasn't it removed from standard to this day. In my opinion the server, I'm going to, should never know where I came from.
I've just done some quick browsing to see if there's a written-down motivation for Referer existing, and there's this on the Wikipedia: "Many blogs publish referrer information in order to link back to people who are linking to them, and hence broaden the conversation."
Which I guess makes sense, in the context of the original use of HTTP as an academic publishing protocol, but it's gained cruft and nefariousness since wider adoption came about.
There are good arguments for stripping Referer from the standard, and yours is one of the most cogent; if Referer is still a thing in another 30 years, I'd be surprised.
In the early days of hypertext there was also a lot of talk of βthe semantic webβ, where one proposal was that all links should be two-way, refer may have been a compromise to let people try to implement that on top of the one-way HTTP/HTML
How do you feel about the internet being "stuck" with an MTU of 1500?
This is kinda the problem with widely deployed standards like TCP/IPv4: if you have even one device out there that's on the "old" standard, it won't be able to talk under a hypothetical new standard like IPv6 or TCP-with-huge-packets. And there are a lot more than one device out there that would be cut off.
As I understand it, the big pipes have very large MTUs now, and the edge routers cut up the packets for further transport. That's probably the only way we can realistically go forward.
Do you think this is the dot com bubble 2.0
If anything, we're into the "bust" part of the bubble: layoffs have been coming in waves all year, and are continuing. There were a whole bunch of posts over on Mastodon just a couple of weeks ago, at end of quarter, where people were laid off and looking for work.
Has anyone implemented it in a physical device?
e.g. RFC3514 (an 'evil' flag you can set in malicious packets so a firewall knows to drop them) was actually used by a few people to see what would happen, with interesting results.
As it turns out, I could find no physical implementations of HTCPCP or the tea-brewing extension. The original protocol is somewhat incomplete, which is probably the main issue; also, any modern appliance would probably talk its own protocol encoded in JSON or similar.
While researching for the talk, I did find Hacked-Together Coffeepot Control Protocol which was a UMaryland hackathon project in 2016. They won the prize for "most technologies used in their tech stack", which is ...something.
So what's better, tea or coffee?