In <38167744153(_dot_)20030107093025(_at_)brandenburg(_dot_)com> Dave Crocker
<dcrocker(_at_)brandenburg(_dot_)com> writes:
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.
Yes indeed, but those are not GENERAL-PURPOSE gateways. They only have to
be capable of meeting the needs of the newsgroup and the community of
users they were designed to serve. That is a simpler problem than a
gateway that will take any article whatsoever out of Usenet and produce a
compliant email out of it.
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.
Yes, that is exactly what I mean. If someone in the newsgroup suddenly
starts using raw UTF-8 in his name (a phrase) or in his Subject, the
existing gateway is unlikely to fall over and collapse. But it will surely
pass on something that has been munged, or will be munged when it arrives
at some User Agent as a mail to be displayed. So the reader will see
something that is obviously not correct (hence my use of the term
"gobbledegook"). It will stick out like a sore thumb. So the sky does not
fall in, but you do not get the benefit of the new functionality.
So what happens? Perhaps they say "This is an English speaking group; why
are these people trying to inflict a foreign language on us?". Not a very
polite response, but Usenet is not always a very polite place :-( .
Or else they say "There are only a few posters doing this, and even though
we cannot decipher their names, their email addresses are still OK, and
their Subjects have a few odd characters, but we can work out what is
going on from the bodies". And so they tolerate the small amount of stuff
coming through.
Or else they say "We should be using this new functionality, and the
amount of it is likely to increase. So we will ask our gateway
administrator to upgrade in line with the new standard".
So, gradually, the new functionality is seen throughout the net, starting
with the places where it is most needed. But, because the quantity is
initially small, it is not a huge problem, and all existing stuff continues
to work as before. So I would describe the problem as "containable".
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.
You will only get data that are illegal with respect to the existing
service if someone is trying to use the new funtionality.
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.
Indeed so. Market forces will win in the end. And Usenet is indeed a
marketplace that is well used to making its opinion felt (IETF or No IETF,
Usefor or No Usefor).
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.
The main advantage that Usenet has over email is that is main
infrastructure - the backbone of relaying agents that carry it worldwide -
is already capable of supporting UTF-8 (indeed any charset) in headers.
Hence the cost of the new functionality need only be born by those who
want to use it - namely the users who may need to upgrade their
newsreaders in order to see the benefits. There are some problems with
moderators, which we have carefully addressed, and some issues with
gateways, as I have described above.
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.
There is a feeling (obviously not shared by all on this list) that that
critical mass of cumbersomeness has already been reached.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Snail: 5
Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5