on SLIDE:
it's potentially useful, but difficult to use.
I suspect it's difficult to implement on any platform which does
not store messages exactly as they are transmitted on the wire,
such implementations would be likely to have errors and the errors
would be likely to produce corrupt messages and/or messages
which contained data not intended for the recipient.
using byte counts on MIME messages doesn't seem like the optimal
strategy. explicit markers in the message might be better.
it needs more discussion of relaying - in particular the need
to adjust byte counts due to received headers being added.
SLIDERANGE parameters could easily get very long, but there
is no advice about how long they should be able to be.
presumably SLIDE would work with BINARYMIME also - document
should probably discuss that. arguably SLIDE should only be
used with BDAT, since an implementation pretty much
has to meet the storage transparency requirements of BINARYMIME
in order to implement SLIDE correctly.
under ordinary circumstances the document would be okay for
experimental. however SMTP extensions have a somewhat higher
bar - we need to believe that they will not be harmful if
deployed. I am uncomfortable with the idea that buggy
implementations of SLIDE might end up in popular MTAs and
that SLIDE would be automatically used if present in EHLO.
suggestions: either don't publish, or (more likely) publish
with some additional restrictions:
- the document needs to be absolutely clear that only messages
originated with SLIDERANGEs can be relayed with SLIDERANGEs,
and those SLIDERANGEs have to correspond to the ranges
chosen by the originator.
(e.g. MTAs shouldn't use SLIDERANGE to relay messages to
several recipients with a slightly different Received
field for each recipient...even though that would be quite
useful...because it would trigger buggy implementations.)
- SLIDE should not be enabled by default; MTAs should need
explicit configuration before advertising SLIDE or acccepting
SLIDERANGE parameters.