Sam,
A few comments about differences in philosophy rather than
specific details of this proposal. Once one gets past that
difference in philosophy, it is not clear to me how much of your
comments are major but...
--On Tuesday, 18 March, 2008 04:51 -0400 Sam Hartman
<hartmans-ietf@xxxxxxx> wrote:
>...
> In particular I believe that the remote-host and remote-ip
> variables are inappropriate and should not be standardized.
>
> I believe an applicability statement should be added to the
> extension making it clear that this extension is only for
> interpreter state and that another extension should be
> designed for examining information about the message.
>...
> Section 4.3.3 claims that experimental RFCs are an appropriate
> mechanism to register non-standards-track variables intended
> for wide use. That seems wrong. I recommend revisiting the
> registration policy.
The bottom line about Sieve is about providing a standard way to
let mail-receiving and mail-reading client machines communicate
with mail server systems about filtering and classification of
mail. Both the client and server systems in the Sieve case
occur after what the mail transport standards refer to as "final
delivery". For practical reasons, there has been general
consensus in the email protocol community for many years that
filtering and classification are better done on always-on/
always-connected/ always-active servers than on mail
receiving/reading machines... if only because of perceived
performance issues with the latter. Part of the elegance of
Sieve is that it tries to be flexible on that subject: if an
operation cannot be specified to and performed on the server,
then it can be acted on by the client, using the same vocabulary
for describing what is to be done. But the main goal, IMO, is
to permit client control of server-side filtering operations
with a standard vocabulary.
The operations and vocabulary that are being specified for Sieve
aren't doing anything new or anything we can prohibit by not
publishing pieces of the specification language or by making
registration difficult. If we keep functionality out of Sieve,
we don't prevent that functionality from being used. We just
impede filtering being offered as a service by multiple-user
email providers, keep those of us who have been doing
server-side filtering and classification for years from doing so
unless we run our own servers and can run scripts and custom
filters there, and push everyone else into client-side filtering
that slows down the perceived performance of mail reading.
Now, use of Sieve is unwise, and perhaps dangerous, if there is
not a fairly strong trust relationship between the client and
server and if the client doesn't have a good model of server
capabilities. I would wish it were otherwise, but that
relationship reflects reality. I personally believe those
issues are adequately covered in the base Sieve materials, but
perhaps you disagree and should be looking for more explanation
there (or elsewhere).
But, because of the nature of this particular beast, I believe
that the debate should be about "is this functionality needed
and in use, perhaps with different syntax and outside of Sieve".
If the answer is "yes", I believe that we should publish and
register if only to provide a common way of doing something. We
might also think the particular function is dumb or dangerous.
However, if we do, the proper remedy, IMO, is to write documents
explaining why people should avoid doing these things --things
that are well-specified-- and what they should do instead,
rather than trying to avoid having them clearly specified.
john
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf