ietf-822
[Top] [All Lists]

prevervation of installed base

2003-01-07 10:49:52

Charles,

I have included segments from your posting that pertain to the question of
impact on installed base.  This issue is fundamental.

To add to Ned's correction, news-> email gatewaying has been around for at
least 20 years, as far as I can recall. Organizations have often wanted to
plug mailing lists into newsgroups. To permit the newsgroup readers to
participate in the mailing list, a news->email gateway is required. In other
environments, the 2-way gatewaying is simply part of a model that lets users
decide how they want to receive and process their group discussion messages.

With respect to the appearance of new capabilities (such as new data formats
and encodings) in the installed base, your use of the term "gobbledegook"
needs to be made more precise. If it means that that a legacy system
receives the data and the data are legal but meaningless -- MIME base64 is
example of this approach -- then it is fine. It permits incremental adoption
without breaking existing systems. The downside for existing systems is that
they do not get the benefit of the new feature, but everything else
continues to work fine.

If it means that the legacy system receives data that are illegal, with
respect to the existing service, then this is not at all fine.
Interoperability requires conforming to a standard, rather than conforming
to it whenever it is convenient. Injecting illegal data is not conforming.

The difference between an upgrade that protects the installed base, versus
an upgrade that requires creating a new installed base is absolutely
fundamental.  Each can be appropriate but explicitly choosing between them
is essential.

The importance of preserving the installed base -- by way of doing an
incremental upgrade rather than a parallel replacement -- is frequently
missed. However the market power of an installed base is massive. Engineers
and vendors ignore it at their peril.

The very strong IETF philosophy has been to try to preserve the installed
base, through optional, incremental upgrade.  It is part of the reason that the
architectural history has been to keep the core infrastructure as simple as
possible.

Infrastructure changes rarely permit incremental upgrade. Hence, a change to
the infrastructure often must be done to the *entire* infrastructure before
there can be benefit to any users. Think about the effort -- and delay --
this requires for a large infrastructure, like the IP Internet, or Usenet. A
delay that is effectively infinite becomes probable when the infrastructure
is very large.

It is certainly true that this approach creates solutions that are ugly. The
encoding aspect of MIME is the epitome of ugliness, in my opinion. And, yes,
incremental ugliness can create an aggregate messiness that eventually
requires complete replacement.  And it is important to look for that
critical mass of cumbersomeness.

But the reason for choosing the MIME ugliness was to permit incremental
upgrade while preserving the installed base -- and to make the upgrade be
strictly in the leaves, with no changes at all to the email infrastructure.

There were previous attempts to introduce multi-media email to the Internet,
through operation of an independent, parallel service that had a multi-media
core.  The installed base ignored those efforts.

d/

Monday, January 6, 2003, 6:39:19 AM, you wrote:
This is perhaps Ned's most important statement.  At countless times in
the last 20 years, the IETF and it's predecessors have chosen backward
compatibility over the "efficient" solution.  ...
 The economic calculation was that clients that care about i18n
can implement IDNA, but that the IETF would not break the "social
contract" made with DNS software that was (and now still will be)
compatible with pre-IDNA standards.

Charles> Yes, it's the tension between the "elegant" solution and the "ugly but
Charles> compatible solution". But there is the added problem that, every time 
you
Charles> adopt an "ugly" solution you make it yet harder again to use the 
"elegant"
Charles> solution next time, ...

Charles>  Breaking
Charles> compatibility for Email could be a serious matter. Breaking 
compatibility
Charles> for Usenet is far far less so...

Similarly, a usefor solution that does not immediately cause existing
software (*including* gateways) to "break" on usefor messages, seems
1000 times more likely to pass IESG muster.  To quote Ned again:

The issue is instead that your approach in effect declares a large
body of software as being no longer compliant with long established
standards. This is something we try very hard not to do.

Charles> Which shows that people have a fundamental misunderstanding of the 
role of
Charles> gateways in Usenet. ...

Charles> But in the reverse direction News->Email, such general-purpose gateways
Charles> just Do Not Exist. ...

Charles> They will appear gradually, in groups where the
Charles> customary language will benefit from them. Users on the far side of
Charles> gateways will notice strange gobbledegook appearing. ...

Charles> No, it's just the inelegance. Plus the fact that the backward
Charles> compatibility issue is nowhere so huge as you imagine. In fact, it is
Charles> rather small.




d/
-- 
 Dave <mailto:dcrocker(_at_)brandenburg(_dot_)com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 t +1.408.246.8253; f +1.408.850.1850


<Prev in Thread] Current Thread [Next in Thread>