In <2147483647(_dot_)1044898411(_at_)nifty-jr(_dot_)west(_dot_)sun(_dot_)com>
Chris Newman <Chris(_dot_)Newman(_at_)Sun(_dot_)COM> writes:
Guide to removing cruft from standard protocols:
1. Write a standard extension to negotiate use of the less-crufty protocol,
and explain how to downconvert to the fully-interoperable crufty protocol.
For sure downconversion is needed at some point in the process, but there
are several points at which you can introduce it:
a) Negotiate it, as you say. Indeed, I have a negotiation suggestion for
email that I have touted on the Usefor list. Very tentative, hairy and
incomplete at the moment, so I would rather not bring it to the ietf-822
list just yet.
b) But sometimes negotiation is impossible (e.g on Usenet the sender cannot
negotiate with all the intended recipients). So you designate boundary
points where downconversion MUST be done (usually at the point where you
are changing from one protocol to another). Later on, when less-crufty
facilities are available on the other side of the boundary, you may be able
to negotiate insteand of downconverting regardless. This is essentially
the approach Usefor is proposing in the present case.
c) Return it to the sender, and get him to downconvert it and send it
again. A bit draconian, you may say, but probably the best way to educate
senders who insist on sending stuff in unidentified charsets. Corollary:
it you think it is spam, omit the "return it" stage :-) .
d) There must be other possibilities too ...
2. Deploy standards-compliant servers and clients that accept the
less-crufty protocol, down-convert if necessary, and will generate the
less-crufty protocol only if negotiated. These interoperate with all
software.
There is a chicken-and-egg problem here. Deployment will not happen until
there is pressure from users. Users cannot use it until it is deployed. So
expect some angry users. Nothing like a bit on anger to get the
implementors moving.
But yes, the implementors need clear specs to work to, so you need at
least an experimental protocol, if not a standard.
3. Deploy non-standard software that generates only the less-crufty
protocol. This software isn't guaranteed to interoperate with everything,
but plays an important role as it creates pressure to upgrade to software
from step 2.
The difficult part is ensuring that stage 2 happens before stage 3. Users
are a pushy lot with a tendency to deploy non-standard stuff even before
the standards exist, let alone are deployed (and Yenc is a good example of
what happens if the standard solutions are not provided in a timely
manner).
The only way to stop that is to retrofit "drop this non-standard stuff on
the floor" features into existing software, and if you are going to that
sort of trouble, you may as well implement the new standard instead.
4. Over time, more and more developers will not bother to implement the
downconversion and cruft-support. Eventually the amount of software
requiring the downconversion is close enough to zero that the standards can
be changed to drop the requirement.
For some suitable value of "eventually" :-) .
--
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