[ih] The Postel Principle

Dave Taht dave at taht.net
Sat Nov 9 17:46:53 PST 2019


Jack Haverty <jack at 3kitty.org> writes:

> Curious.  I never received that message from Brian.  Internet Managers,
> what's the problem with your networks' mail service!!?  Ohh, not
> you...who do I talk to?... Why are you all pointing fingers?    [Sigh.]

I finally disabled IPv6 on my email exchangers today. For no reason
I can figure, every use of it put me in spamhaus's SBL blacklist,
for most of the past year, if not longer.

The only thing different from the spec I do, is that I make starttls
mandatory on recieve. This blocks at least 98% of the spam from getting
through.

I am sad that email is dying, and sadder still that using it (lacking
effective reverse dns) requires your mail servers live in the cloud.

>
> I looked at that draft iab document, and the abstract brought a sense of
> deja vu:
>
> "The robustness principle, often phrased as "be conservative in what you
> send, and liberal in what you accept", has long guided the design and
> implementation of Internet protocols. The posture this statement
> advocates promotes interoperability in the short term, but can
> negatively affect the protocol ecosystem over time. For a protocol that
> is actively maintained, the robustness principle can, and should, be
> avoided."

Ignorance is Strength.

Using my starttls example above, it would be good if we would revise
standards a bit more often than once a decade.

>
> I recall having exactly that discussion with Jon back in the day, when
> we were both on the ICCB(IAB).   Several times.  My much less eloquent
> argument was that you should fix bugs, not let them fester forever
> hidden by bandaids of "be liberal".   If there's a bug, report it, and
> make an interim workaround if possible.  Otherwise you're just laying
> land mines hidden in flawed code all over the Internet that will some
> day blow up and be much harder to fix.   It's similar to dealing with a
> new nasty virus - find Patient Zero, contain the problem and get it
> fixed asap before it explodes as a pandemic.

Fixing stuff in the open source world is so easy nowadays, and many
OSes are updated essentially daily.

>
> I lost that argument with Jon about the Robustness Principle, but have
> always been supportive of Consensus and Code - and you pragmatically
> couldn't get consensus unless you had running code.
>
> I must shamefully admit that I haven't been following RFCs since about
> when they became 4-digit numbers.  Maybe it exceeded the number of bits
> in some header field in my brain.  I had been fighting such kinds of
> "interoperability" fights for a while - e.g., see
> https://www.rfc-editor.org/info/rfc722 which came about during the email
> wars, errr, discussions in the 70s.

The future we live in now is about platforms, not protocols.

Slack - a chat alternative - had a 6B IPO. It will last until they try
too hard to monetize it with advertising, or given what I know the costs
are in maintaining the irc network, survive off the interest.


>
> Sounds like 2019 is when those land mines are becoming an issue...
>
> /Jack
>
>
> On 11/9/19 10:15 AM, Dave Taht wrote:
>> Brian E Carpenter via Internet-history
>> <internet-history at elists.isoc.org> writes:
>>
>>> This deserves to be a new thread. It turns out to be a warm, if not hot, topic.
>>>
>>> On 09-Nov-19 15:32, Jack Haverty wrote:
>>>
>>>> In the annals of Internet History, did Jon Postel's mantra of "Rough
>>>> Consensus and Running Code" fade away over time?
>>> First, read this draft:
>>> https://tools.ietf.org/html/draft-iab-protocol-maintenance-04
>>>
>>> There's a discussion thread at:
>>> https://mailarchive.ietf.org/arch/browse/architecture-discuss/?gbt=1&index=jBCAqATbCy0kzt8bR_59LNlWjCU
>> I have tended to revser the dictum - RUNNING code and rough
>> consensus. It seems to be the only way to make progress.
>>
>>> As you will see, your question is apposite to that draft. I'm a bit
>>> biased, because I was document editor for
>>> https://tools.ietf.org/html/rfc1958 and of course Jon had a hand in
>>> that.
>>>
>>>     Brian




More information about the Internet-history mailing list