Slashdot Mirror

I hope this gets update to comply with RFC 5785. There are far too many people inventing "special" URLs at the root level of sites, which are likely to clash with pages that already exist. RFC 5785 says that such URLs should be like http ://example.org/.well-known/security.txt instead of http ://example.org/security.txt . That way, they won't clash with existing pages. RFC 5785 also defines a registry for these URLs, to avoid the situation where two specs define different meanings for the same URL.

RFC 561 called for standardizing mail headers 5 years before Ayyadurai claimed he invented it. While email has never formally defined when it was first used in the 1960s, the different standards slowly evolved. This is why it's hard to pin down when or who invented email as it slowly became what it is with many refinements and contributors. Back then different computer systems used different protocols, etc.

https://tools.ietf.org/html/rf...

Network Working Group J. White
Request for Comments: 524 SRI-ARC
NIC: 17140 13 June 1973

  A Proposed Mail Protocol
AUTHOR'S INTENT
  This is the document I offered in (15146,) to write. It's a proposed
  specification for handling mail in the Network -- a Mail Protocol....

https://tools.ietf.org/html/rf...

  RFC # 561 Abhay Bhushan (AKB) MIT-DMCG
  NIC # 18516 Ken Pogran (KP) MIT-MULTICS
  Ray Tomlinson (RST) BBN-TENEX
  Jim White (JEW) SRI-ARC
  5 September 73
  Standardizing Network Mail Headers
  One of the deficiences of the current FTP mail protocol is that
  it makes no provision for the explicit specification of such
  header information as author, title, and date. Many systems
  send that information, but each in a different format. One
  fairly serious result of this lack of standardization is that
  it's next to impossible for a system or user program to
  intelligently process incoming mail.

https://tools.ietf.org/html/rf...

Network Working Group J. White
Request for Comments: 524 SRI-ARC
NIC: 17140 13 June 1973

  A Proposed Mail Protocol
AUTHOR'S INTENT
  This is the document I offered in (15146,) to write. It's a proposed
  specification for handling mail in the Network -- a Mail Protocol....

https://tools.ietf.org/html/rf...

  RFC # 561 Abhay Bhushan (AKB) MIT-DMCG
  NIC # 18516 Ken Pogran (KP) MIT-MULTICS
  Ray Tomlinson (RST) BBN-TENEX
  Jim White (JEW) SRI-ARC
  5 September 73
  Standardizing Network Mail Headers
  One of the deficiences of the current FTP mail protocol is that
  it makes no provision for the explicit specification of such
  header information as author, title, and date. Many systems
  send that information, but each in a different format. One
  fairly serious result of this lack of standardization is that
  it's next to impossible for a system or user program to
  intelligently process incoming mail.

His claims were always far-fetched. Correctly he claims a copyright over a program called "EMAIL", however that does not mean he invented email itself which predates him by over a decade. In fact RFC 561 outlines standards for email headers 5 years before his program. As an analogy it would be like Microsoft claiming they invented spreadsheets because they came out with Excel. Lotus Corp and many others would dispute that claim.

claimed that he invented e-mail in the late 1970s.

Err, isn't RFC 561 trivially prior art?

Here's the example from the RFC, which also provides some BNF style formal syntax:

From: White at SRI-ARC
Date: 24 JUL 1973 1527-PDT
Subject: Multi-Site Journal Meeting Announcement
NIC: 17996

                      At 10 AM Wednesday 25-JULY there will be a meeting
                      to discuss a Multi-Site Journal in the context of
                      the Utility. Y'all be here.

1973. That's certainly before the "late 1970s".

I think we should call it the anti-evil bit https://www.ietf.org/rfc/rfc3514.txt !

Did it comply with this RFC?

https://www.ietf.org/rfc/rfc3514.txt

Lies. RFC 3514 solved this problem long ago, but big government colluded with big business as usual to prevent it from happening. Corporations are the worst. It was so they could spy on us as a prelude to 9/11, which was in planning. Google wtf 7 learn the truth.

The real problem is that, yet again, systemd has been involved in critical functionality breaking in an unusual and unexpected way.

No, the real problem is that Netflix violated RFC 1034 section 3.5 and RFC 1035 section 2.3.1, which both explicitly say that hostnames must still conform to the old ARPANET restrictions, which allow only letters, numbers, and hyphens. Underscores have never been legal in DNS hostnames, and in spite of the pain this spec-compliant behavior has caused for some users, the systemd behavior is correct, and Netflix needs to fix whatever broken software they have that incorrectly created an invalid hostname containing an underscore.

The remarkable thing, frankly, is that any DNS resolver resolved that address, and more significantly, that the DNS servers actually responded to the request.

The real problem is that, yet again, systemd has been involved in critical functionality breaking in an unusual and unexpected way.

No, the real problem is that Netflix violated RFC 1034 section 3.5 and RFC 1035 section 2.3.1, which both explicitly say that hostnames must still conform to the old ARPANET restrictions, which allow only letters, numbers, and hyphens. Underscores have never been legal in DNS hostnames, and in spite of the pain this spec-compliant behavior has caused for some users, the systemd behavior is correct, and Netflix needs to fix whatever broken software they have that incorrectly created an invalid hostname containing an underscore.

The remarkable thing, frankly, is that any DNS resolver resolved that address, and more significantly, that the DNS servers actually responded to the request.

But once it's published, it's pretty much ratified. Here's the mess https://www.ietf.org/rfc/rfc31...

Are Millennial software developers actually unfamiliar with the Robustness Principle, also called Postel's Law, of RFC 761?!

be conservative in what you do, be liberal in what you accept from others

In this case the correct behavior is clear: accept the hostname with an underscore, even if it may not be standards-conformant, and try to resolve it anyway.

Remember, the point of computers and computing is to help the user accomplish what it is they want to do. The point is not to let software developers act out their Asperger's-inspired tyrannical urges over something as insignificant as a minimally malformed domain name.

Underscores are not allowed in domain names.

That has not been the case and is not the case currently. RFC 2181 dictates differently and more specifically section 11 of said RFC.

I would argue that an email address is an identity, and that using one which does not belong to you to create an account on a public system is identity theft.

No, it might be an identifier theft, but that issue would only arise if the legitimate address holder will in turn open an account at the same web site. The first user noticed that the identifier was accepted, and considers such acceptance a probative evidence of his right to use the identifier, on a first come first served principle. She or he doesn't have to know whether that identifier was supposed to be globally unique. The SMTP standard is not law. Actually, it is not even an Internet standard, it is merely a draft. Why should people not interested in email take care of it?

I know identity theft is a crime, but the unintended collider didn't actually steal anything, so I don't think she or he can be prosecuted. As for taking the law into one's own hands, it is certainly not allowed.

Personally, I would blame the websites, which should not use address-like identifiers if they are not going to verify they're valid. However, now that you said it, I recall my brother managed to unintentionally steal my Blockbuster account —which wasn't associated with any email address— just because he has the same surname as I. Perhaps DNA sequences...?

Ah yes, they had the "Evil Bit" set.

This reminds me of a satirical piece by Mark Boslough about the Alabama state legislature wanting to change the value of Pi from the irational value of 3.14159... to the simplier biblical value of 3.

https://en.m.wikipedia.org/wik...
http://www.huffingtonpost.com/...

And of course, not to mention back in 1897, when the Indiana state legislature seriously considered defining Pi to 3.2.

https://en.m.wikipedia.org/wik...

This is especially interesting considering that the seeds for the Brainpool elliptic curve domain parameters, used for crypto especially in European passports and government ID cards, were defined over values from "Pi" & "e".

http://www.ecc-brainpool.org/d...
https://tools.ietf.org/html/rf...

Maybe Australia will ban Europeans with their unbreakable crypto in their passports from visiting?

I accuse YOU of ILLEGAL PACKET PRIORITIZATION for refusing to let me RFC 1149 pigeons land!

There actually is a way to tell the other side you want TLS. It's called DANE (RFC 7672). It's new and not widely used yet.

Here's a presentation on the topic:
https://www.ietf.org/proceedin...

Not sure why they went their separate way for this though.

AOMedia and NetVC are not separate efforts, they complement each other. The same people involved with NetVC work on AV1. NetVC will use AV1.

It has already had an impact.
For those who won't bother to follow the link, Mark Nottingham said of QUIC meetings:

2) We won't hold any further interim meetings in the US, until there's a change in this situation. This means that we'll either need to find suitable hosts in Canada or Mexico, or our meeting rotation will need to change to be exclusively Europe and Asia.

SNTP is broken by design, and should never have been used for anything important. RFC4330 states that it has "accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC 868." RFC868 is literally two pages long and is essentially "client sends packet to server, server sends packet containing current number of seconds since epoch, client sets time."

Naturally Pottering's excuse for all of this shit is that distributions should not just package whatever shit he crapped out.

SNTP is broken by design, and should never have been used for anything important. RFC4330 states that it has "accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC 868." RFC868 is literally two pages long and is essentially "client sends packet to server, server sends packet containing current number of seconds since epoch, client sets time."

Naturally Pottering's excuse for all of this shit is that distributions should not just package whatever shit he crapped out.

1. The most dangerous ones can easily pretend to be non-Muslim, or having converted to Christianity to enter the US and wreak havoc. So security improvement argument doesn't hold much. See the solution to all computer security problems : Evil bit.

2. If the country (say the US) wants to prohibit wife hitting, they should prohibit wife hitting. Why the round-about way of reducing the number of Muslims brought in from abroad ? This will protect against lunatics , whether Muslim or followers of phalrehuq religion, whether already in the country or coming in from abroad.

In even more generality, just prohibit hitting.

3. Practically, being an interconnected country and the world - we are in more danger from people being offended in a real or perceived fashion. So this unnecessary, insufficient "ban" would make the country even more insecure from the people having say business or family impact from this move.

Who's complaining? I was correcting ignorance. VP8 support is mandatory to implement in the WebRTC spec. sl3xd didn't understand that.

As mentioned in the summary: RFC 6716.

Cisco is promoting NETVC

What are you talking about? NETVC is not a video format. NETVC is an IETF working group and it's not distinct from AV1. The people participating in NETVC also work on AV1. The conclusion of NETVC's work will be "Let's use AV1".

I'm done with that BS.

The standard for web formats to meet is that they be royalty-free. Formats which aren't royalty-free are antithetical to the web. Video is not special in this regard and all we're seeing now is that the royalty-free video formats are winning out over the royalty-bearing video formats. AV1 will continue this trend. HEVC is a dead end format. Use VP9 today and use AV1 tomorrow.

You may not want to be part of the projects, but it is practically unavoidable that you use projects that have a code of conduct. Even the Internet Engineering Task Force (IETF) has a code of conduct and they publish a lot of important bits.

Unlike HEVC, in order to use VP9, Apple would have to grant Google free use of its patents (VP9 has a whole patent reciprocity agreement - much like the GPLv3).

Free use of all patents owned by Apple Inc. and its subsidiaries, or only of those patents essential to VP9? The reciprocity provision of the additional patent grant for VP8 and VP9 appears to apply only to patents related to those codecs.

VP9 has a big user base because it's promoted by an industry giant, but it is not an international standard

What organizations qualify to set "an international standard"? If IETF counts, then VP8 is RFC 6386, and standardization of VP9 is ongoing.

Businesses that rely on geo locks? Those businesses SHOULD die off.

I'm afraid those businesses haven't read RFC 2119.

Fair enough, but those examples only apply to poorly-considered naming schemes (and the accompanying human assumptions) or improperly implemented mail systems. Per RFC 5321, "the local-part of a mailbox MUST BE treated as case sensitive." These could lead to multiple identifiers that all map to a single email address (in the case of a case insensitive local-part), but not a single identifier mapping to multiple email addresses (the birthday paradox manifestation).

The fuzzy matching was more about the fact that every time you "read" a biometric property, you have a good chance of getting a slightly different reading. A biometric property is not a static property that can be read with 100% fidelity. The standard approach to handling this is to pick a number of the (assumed or measured to be) most invariant features use those as the reading, tossing out the rest. This process is not very robust, though, and you determine acceptable matches by whether the matched features to total features ratio exceeds a threshold (fuzzy matching). Barring shitty programming or improper assumptions, email addresses can be read with 100% fidelity and either match or don't match an entry in your database. Any fuzziness is deliberately imposed on an inherently non-fuzzy system.

Yup, there have been cases recently where people have used photographs to get a person's fingerprints. Amazing but true.

Getting rid of passwords is a good idea, though. It's just that replacing them with biometrics is a change for the worse. A change for the better is to use public key cryptography: instead of your keychain containing passwords that you have to remember and that are sent to the far end, you have public keys, possibly more than one, for every service you need to contact, and you use your private key to authenticate with them. Trust is established at first use, or in person (with your bank).

There's work being done on this in the IETF, using token binding. It's early days, but you can enable it in Chrome. Dunno if it's in Firefox yet.

https://tools.ietf.org/html/rf...

The obvious (and already available) solution is to have the spider mark its incoming HTTP request at the TCP level appropriately:

https://www.ietf.org/rfc/rfc35...

Rgds

Damon

https://en.wikipedia.org/wiki/IPv6_address:

Discard
0100::/64 — This prefix is used for discarding traffic.[33]

#33. RFC 6666, A Discard Prefix for IPv6, N. Hilliard, D. Freedman (August 2012)

RFC6666:

Abstract
Remote triggered black hole filtering describes a method of mitigating the effects of denial-of-service attacks by selectively discarding traffic based on source or destination address. Remote triggered black hole routing describes a method of selectively re-routing traffic into a sinkhole router (for further analysis) based
on destination address. This document updates the "IPv6 Special Purpose Address Registry" by explaining why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitating IPv6 remote triggered black hole filtering and routing.

RFC 6598 -- http://tools.ietf.org/html/rfc...

No.

Oblig. rfc2549

The real information war is between centralized control of narratives and technology. When people have choice, and many choose to believe crazy things (sort of like when Luther posted his 95 theses), it leads to a lot of "social disruption" (like "the European wars of religion".

Well, that's just too bad.

If people want to fight the information war, they need to target the current Internet routing architecture that is recentralizing narrative into network effect monopolies emerge like YouTube, Twitter, etc. that have openly controlled access by content providers based on political content.

Read the first link in this post, and if you find that prescient for 1982, then consider this prescient as well:

Deploy Information Centric Networking to fight the recentralization of narrative.

"there is no man-in-the-middle or DNS hijack or proxy etc. It is not to verify the identity "

If the identity of the endpoint can't be verified, exactly how is it that MITM is prevented? Are MITM sites required to set the Evil Bit?

LEO satellites aren't worth it. You get high latency and high cost.

I expect Google will end up deploying a wireless network based on RFC1149. The latency sucks, but you can't beat the price.

The first time I looked at that URL (all lowercase, as in TFS)

Domain names are not case sensitive (RFC 4343). The remainder of the URL may be (and frequently, not not always, is), depending on the host software. This is also true for SMTP addresses.

It's a sad commentary on the current state of /. that you felt compelled to explain what should be (and would have been just a few years ago) common knowledge to the site's readership. Here's the reason I mentioned the casing of the URL as presented in TFS: as you may have noticed, domain names are frequently presented in mass marketing with casing in order to clarify/emphasize what the site is about or to make it easier to remember what may be a long string of characters. "IsItDownRightNow.com" and "ISitDownRightNow.com" are both easy to remember, but lead the average person to different conclusions; "isitdownrightnow.com" leaves it to the parsing peculiarities of the reader.

The first time I looked at that URL (all lowercase, as in TFS)

Domain names are not case sensitive (RFC 4343). The remainder of the URL may be (and frequently, not not always, is), depending on the host software. This is also true for SMTP addresses.

Bloat, yes, bufferbloat, no.

Recently I made a trip to nicaragua and deployed a few fq_codel and cake equipped routers there. The effects were *marvellous*. The kind of total failure to load problems dan describes, in particular, went away.

Still, I'd like to banish those that think IW of greater than 2, TSO and GSO, and 6 simultaneous connections in web browsers - as a good idea - to remote locations for a while, until they learn the errors of their ways.

https://tools.ietf.org/html/dr...

is also a good read.

Turns out it's rather simple, really --- just ban computers. He's going to start by replacing computers with human couriers for the secure-messaging market, and move outward from there. By 2020 we should have most of the Internet replaced by the (now greatly expanded) Post Office.

Don't be ridiculous. There are not enough people in this world to hand deliver each and every packet of data that needs to be sent around the world. I propose that we use this standard in order to overcome this serious problem.

I am not huge on basic web tests, preferring the finer grained results we get from flent. (https://flent.org).
And I totally agree that the trendline is to ever more devices doing ever more stuff randomly when you least desire it. We need to have edge routers AND ISPs ready for this change in traffic patterns.
The article you cited was quite good, although it missed completely the outputs of the ietf aqm working group, of which both I and fred baker are members.
https://tools.ietf.org/wg/aqm/

It is entirely probable we've been inside our own filter bubble so long (6 years) we cannot properly communicate with first time readers! some folk explaining the problem... the ietf video shows the benefit from fixing it. https://www.bufferbloat.net/pr... showing the extent: http://www.dslreports.com/spee... you have this entirely backwards: "Buffering can reduce latency, especially under heavy load, by better bandwidth utilization, and allowing faster retransmission of dropped packets. If it is slowing things down, then you should fix the buffering rather than eliminating it." You want enough buffering to absorb bursts, but any more just adds latency. Van Jacobson and kathie nichols calls this distinction good queue and bad queue: https://tools.ietf.org/html/dr... Less buffering (and fair queuing) allows for faster retransmission in particular.

I believe evidence. Actual, verifiable evidence.

I believe the Wikileaks dumps because we can do DKIM validation on them. I can pull the keys off of Clinton's & Google's DNS servers (they're simple TEXT records, go read the RFC if you want details). I believe in looking at cui bono (who benefits). It's normally hard to fake that, especially in things that are tightly contested where you can't afford to act against your own interests. I believe in looking at the timing of things, especially in those cases when it can't be faked. I believe in looking at someone's history of truthfulness (or falseness), how well they can explain their mistakes, and how well they come clean when they were wrong about something.

But you're right. They're all playing us for their own benefits right now. That's why I trust cooperation based on mutual self-interest, but I don't think that Russia, China, Saudi Arabia, Qatar & co. are looking out for anyone but themselves. But nor am I dumb enough to ignore which interests are opposed and which ones coincide with ours.

So yes, by all means. Be skeptical of all the motives out there, even mine, and look for actions, not words, as proof.

If you already have a domain name, you can add the dynamic host name as a cname to your DNS servers, which should be other than your home system anyway.

By RFC2181, you shouldn't point an NS record to a CNAME. Instead, run your DNS server on your home network (so that you aren't trusting DNSSEC keys to a remote server) and use a backup DNS service to maintain service whenever your IP changes.

So how will the request filter know who is and is not an MP?

Simple. A special bit is dedicated for traffic from MPs: https://www.ietf.org/rfc/rfc35...