At 12:02 03-01-2009, Dave CROCKER wrote:
This thread's taking place on the main IETF list, so it's probably
worth noting some deeper issues that your observations raise:
1. Should an adjunct protocol modify core semantics of the primary
protocol, rather than add semantics to it? If yes, when yes and when no?
The adjunct protocol shouldn't modify core semantics if it is built
upon the primary protocol.
Cavalierly modifying core semantics creates incompatible
variants, and distributes their definition into unlikely places.
Yes.
2. If a protocol has a features that remain unexercised for a long
time, when is it appropriate to deprecate it? To make the exercise
a bit more challenging, take note of situations in which the
protocol is modeling well-established behavior from elsewhere in the
world, but which nonetheless is not a behavior that has (yet) shown
up in use of the protocol.
There is a difference between features that remain unexercised and
features that are obsolete. If we want to depreciate a feature
during a protocol update, we make a case for it.
What we have here is a case of a protocol's supplying
functional variety that models the real-world, but which has
remained virtually unused for 30 years. One can easily argue that
the deeper "problem" is that Internet Mail remains a limited
functionality that will yet expand to fill the roles we know --
from the paper world -- are yet needed. But even if we restrict
the historical review to the start of the mass market Internet
(1994) we are still looking at 15 years of not expanding into that
available functionality. Failure to use a feature for that long
makes a strong case for deprecating it.
If we are going to use that line of argument, we would depreciate a
lot of features which seem unused because well-known mail clients do
not implement them. I don't see a strong case as there are some mail
clients that implement the feature.
Regards,
-sm
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf