[rfc-i] Does the canonical RFC format need to be "readable" by developers and others?

Martin Rex mrex at sap.com
Thu Jul 5 16:44:53 PDT 2012

"Martin J. Dürst" wrote:
> Martin Rex rote:
> >
> > Correct, it is the strict/full backwards compatibility that counts.
> > There is a disappointing low number of languages that tries hard to
> > *NOT* break existing code, even when adopting new features.
> >
> > When the version numbering of the language is explicitly designed to
> > break backwards compatibility, then it is problably a language not
> > worth using for anything where longevity matters.
> What matters for the RFC series is the stability of the format and its 
> semantics. XML itself is extremely stable, in particular as far as we 
> are concerned for RFCs.

Going for an XML-requirement for I-D/RFC submission would be similar
to switching the IETF and I-D/RFC content language from English to
Esperanto, Ido or Interlingua.

Backwards-compatibility, ease-of-use and simplicity are important
prerequisites for continuity and longevity.

The IPv6 folks IMO did not sufficiently think through what they were doing,
and created a big mess.  Had they taken a more conservative approach,
the whole world would be better of today.  But instead, they created the
current mess, leaving us with having to implement, support and required
to transparently run on two entirely seperate internets for at least
20 more years.

When looking at some significantly more complex/sophisticated technology
than one what is currently using, one should REAAAALLLY make an assessment
how difficult it will be to revert and get rid of that stuff when it turns
out be much less attractive to NEW consumers, than to the die-hards that
are already accustomed to the technology for other reasons.

Moving away from plain ASCII is magnitudes easier than moving away from
XML, which is why ASCII is a pretty good choice in the first place.


More information about the rfc-interest mailing list