Re: [arch-d] deprecating Postel's principle- considered harmful

[Henning Schulzrinne <[e-mail]>]

I think the problem is an interaction of poor programming and inability to
reach implementers (and then the consequences). For example,

* Some major open source or big-company server implementation allows lots
of variation beyond the spec.
* Then, clients test against this implementation and declare "ready to
ship" when the bits flow without error messages. Programming is mostly done
based on examples and a casual reading of the spec. In text protocols,
spacing, line breaks, capitalization, ordering and other variations are
done by "feel" rather than ABNF.
* Since implementers usually have no good way to reach other implementers
(or assume a timely response or well-informed response), they have to make
expedient choices, making the problem worse over time.
* As noted in the draft, this now means that everyone has to be
bug-compatible, raising the complexity in code and testing, and probably
further entrenching dominant implementations.
* Buggy small-scale implementations become major clients or servers, so
what was excusable as a no-impact hobby project becomes a burden on
everyone else.

Thus, dominant implementation have a particular responsibility as their
"leakiness" pollutes the larger eco system. Low market-share
implementations have to go with the flow, as a random hobbyist has little
hope of getting a Fortune 500 company to change its errant ways.

It would be useful to have protocol syntax checkers that would indeed be
strict, just as we have for JSON (with the limits noted in the draft) and
XML and if there was a torture test for the legitimate variations in syntax
or protocol flow. It would be nice if the document made a few
recommendations besides the "don't do that" aspect.

The document doesn't mention this, but my perception is that this is
particular problematic for protocols that roll their own text-based or
complex, nested binary syntax. Hard to avoid for the early Internet
protocols; probably a bad idea now. Besides the TLS example mentioned, this
seems less of a problem for TLV and other binary protocols, but maybe there
are other examples of undocumented behavior that I'm not aware of.

A variation not mentioned is that we now often seem to have to have two
versions of the same encoding: a generic one that leaves lots of room for
"creativity" (white space and ordering and ...) and a canonical version for
signing with much tighter rules. This seems less than ideal. We have done
this now for ASN.1, XML, JSON and CBOR, I believe.

Henning

On Tue, May 7, 2019 at 4:48 PM Andrew G. Malis <[e-mail]> wrote:

> Barry,
>
> Except in the cases that you cite (badly formed messages in email and web
> applications), the Postel principle isn't being followed, as the senders
> are not being strict in what they send.
>
> The intention, really, was to prevent implementations of a
> particular version of a specification that, for example, had a field or bit
> that Must Be Zero, from discarding an incoming message just because that
> field or bit wasn't actually zero. This allows a protocol to be updated
> without requiring a flag day or forklift.
>
> So what you're trying to prevent is poor application programming that
> doesn't follow the spec (any revision). I don't agree that poor application
> programming is a result of the Postel principle, it's a result of
> incompetence or laziness.
>
> Cheers,
> Andy
>
>
> On Tue, May 7, 2019 at 4:30 PM Barry Leiba <[e-mail]>
> wrote:
>
>> I think the questions Deborah raises are layer-dependent, and it's
>> likely that I agree with Martin more than Deborah does exactly because
>> Martin and I live at the same layers.
>>
>> > It just erroneously blames Postel for sloppy implementations.
>>
>> Blaming the principle isn't the same as blaming Postel; the point here
>> isn't so much that "Postel was wrong" as it is that there are many
>> consequences of adhering to that principle that Jon didn't anticipate.
>> The classic cases here are in email and web applications, where what
>> one might call "loose" use of the protocols has resulted in some real
>> messes.  Acceptance of badly formed messages has led to widespread
>> sending of badly formed messages, to the point that it's caused
>> problems with the integrity of the email system.  In web applications,
>> poor implementation of things like character set and content type
>> labelling has resulted in great difficulty in figuring out what
>> character sets and content types are really meant.
>>
>> So the general thing is that if we were *not* liberal in what we
>> accepted, from the start, aberrant implementations would never have
>> worked in the first place, and would either have been fixed or died on
>> the vine.  And that would have been far better for the Internet as a
>> whole than what we have now, at least at the higher stack layers.
>>
>> My sense is that at the lower stack layers, we're *not* actually very
>> liberal in what we accept, at least not in general.  Saying, there,
>> that the principle we're talking about is correct and good for the
>> Internet is really saying that the principle works only when it's used
>> sparingly and in targeted ways.
>>
>> Barry
>>
>>
>> Barry
>>
>> On Tue, May 7, 2019 at 3:18 PM BRUNGARD, DEBORAH A <[e-mail]>
>> wrote:
>> >
>> > Not seeing much discussion on this document on the lists, I put a twist
>> on the title-
>> >
>> > I find the document (as currently written) is incorrectly interpreting
>> the robustness principle as saying there is no need for clear rules on
>> protocol evolvability/extensions. For example, section 6, "relying on
>> implementations to consistently apply the robustness principle is not a
>> good strategy for extensibility". In the routing area, we do have rules and
>> we use the principle to ensure interoperability, as we don't have the
>> luxury to do a "forklift". Section 8's "it is not always possible to
>> produce a design that allow all current protocol participants to continue
>> to participate", my question would be "but does it harm the network"?
>> >
>> > Actually most of the document confusingly is not contradicting Postel's
>> principle but supporting it (except for the nuances which seem to condone
>> forklifts). It just erroneously blames Postel for sloppy implementations.
>> For the document to summarize saying "the robustness principle can, and
>> should, be avoided" as it is harmful (I think) will be harmful to the
>> Internet.
>> >
>> > Hopefully more folks will read it-
>> > (probably discussion is more appropriate on the architecture-discuss
>> list)
>> > Deborah
>> >
>> > -----Original Message-----
>> > From: IAB <[e-mail]> On Behalf Of [e-mail]
>> > Sent: Monday, May 06, 2019 10:40 PM
>> > To: [e-mail]
>> > Cc: [e-mail]
>> > Subject: [IAB] I-D Action: draft-iab-protocol-maintenance-03.txt
>> >
>> >
>> > A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> > This draft is a work item of the Internet Architecture Board IETF of
>> the IETF.
>> >
>> >         Title           : The Harmful Consequences of the Robustness
>> Principle
>> >         Author          : Martin Thomson
>> >         Filename        : draft-iab-protocol-maintenance-03.txt
>> >         Pages           : 11
>> >         Date            : 2019-05-06
>> >
>> > Abstract:
>> >    Jon Postel's famous statement of "Be liberal in what you accept, and
>> >    conservative in what you send" is a principle that 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.
>> >
>> >
>> > The IETF datatracker status page for this draft is:
>> >
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Diab-2Dprotocol-2Dmaintenance_&d=DwICaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=VZUxXboWY44rtZcmcswiLQuQ8TmW6g7F7Azgl-j0amw&s=Fxp9wRoCVRJ_8BZBzY1MoExjRlVCegLbFtq8txcr6F8&e=
>> >
>> > There are also htmlized versions available at:
>> >
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Diab-2Dprotocol-2Dmaintenance-2D03&d=DwICaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=VZUxXboWY44rtZcmcswiLQuQ8TmW6g7F7Azgl-j0amw&s=aCbWfZ2WFHlTnh7WeiI8hJ_N04EoyW90y-Wuml8gLuA&e=
>> >
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Diab-2Dprotocol-2Dmaintenance-2D03&d=DwICaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=VZUxXboWY44rtZcmcswiLQuQ8TmW6g7F7Azgl-j0amw&s=lBVwS9yzx9lBmBEMA0cIidmh_hgRqGFclGMt6iNTPfw&e=
>> >
>> > A diff from the previous version is available at:
>> >
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Diab-2Dprotocol-2Dmaintenance-2D03&d=DwICaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=VZUxXboWY44rtZcmcswiLQuQ8TmW6g7F7Azgl-j0amw&s=JdV3Cux54CLr3GLrhc4SapVMu0mBchg-65xKrwqYPCo&e=
>> >
>> >
>> > Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at
>> tools.ietf.org.
>> >
>> > Internet-Drafts are also available by anonymous FTP at:
>> >
>> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=VZUxXboWY44rtZcmcswiLQuQ8TmW6g7F7Azgl-j0amw&s=FA3-28RGBPX6oeQnIR42NBpfekSVh-BU7wyHCkuesdA&e=
>> >
>>
>> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>