Re: Last Call: draft-freed-sieve-environment (Sieve Email Filtering: Environment Extension) to Proposed Standard

[Ned Freed <[e-mail]>]

> This extension appears to conflate two unrelated things: information
> about the interpreter context and information about the message.

Not really. The information environment supplies is, as the name implies, about
the environment things are operating in. This includes information about the
Sieve interpreter, the host it is running on, and the network. The last item
includes connection information, which is in no way specific to a particular
message - a connection can  relate to many messages.

> I don't think these two sets of information are similar enough that the same
> interface should be used to get to both of them.

Then by all means provide an example of some sort of information that requires
sufficiently different handling in the Sieve context to warrant having two
different extensions to obtain it. (Or even three if you wanted to separate
interpreter information from host information.)

Absent a compelling reason why different bits of environment information
require different extensions to access I think the present approach of simply
using a single extension is far preferable.

> In particular I believe that the remote-host and remote-ip variables
> are inappropriate and should not be standardized.

Why not? These pieces of information are commonly used in Sieve scripts. Right
now the approach people often take is to grub around in the outermost Received:
field looking for this stuff. But this approach is extremely unreliable given
the widely varying formats used by different implementations, to say nothing of
the fact that message flows within an implementation can also vary widely, and
leads to nonportable and unreliable scripts. The main goals of environment are
to improve script portability and reliability, both by providing contextual
information that can be used to tailor script actions but also by eliminating
the need to grub around for information the script needs.

Now, perhaps you object to scripts using IP addresses as some sort of layering
violation. If that's the case then I'm sorry, but this particular horse left
the barn decades ago. IP address and host name information is consumed
routinely as part of message filtering activities and while I along with many
others wish things didn't have to be done this way it is nothing short of
delusional to pretend it isn't.

> 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.

Given that none of the information provided by any current defined item is
about the message per se I fail to see the point.

> I find the string "MUA" meaning anything that happens after delivery
> confusing.  I'd suggest another string--possibly "POST-MDA" and
> reserve "MUA" for sieve scripts actually executed inside a MUA.
> Alternatively perhaps "MUA" could mean the script is executed at the
> direction of the MUA.  That's not quite the same thing as
> post-delivery.

Well, according to draft-crocker-email-arch-10.txt, an MUA is a thing that
"works on behalf of end-users and end-user applications. It is their
'representative' within the email service." This would seem to cover
essentially all message processing activities prior to submission and after
delivery, not just those done from the subset of software you personally
consider to be an MUA.

That said, I have no objection to there being a little more granularity in the
MUA space, although in most cases I'm pretty sure it is going to be a
distinction without a difference. However, I have to wonder if (a) This small
and simple Sieve extension is the right place to conduct such an exercise in
defining new agent taxonomy and (b) Given how difficult it has been to get
consensus on the very limited and general set of terms used in the email
architecture specification, how much harder it is going to be to get agreement
on these distinctions in user agent space.

Now, one legitimate issue that this does point oout is that there is in fact a
value missing from the current enumeration: Store. In particular, here is that
of attaching Sieves to various parts of draft-ietf-lemonade-imap-sieve-05.txt
extends Sieve to be applicable when actions are taken on messages in the
message store. This in turn leads to a case where a number of Sieve tests and
actions cannot be performed and others have somewhat different semantics. This
type of evaluation is therefore a distinction with significant difference and
warrants its own evaluation-agent value. In fact there are finer distinctions
in the context of the store Sieve evaluations, but the draft in question
addresses this by defining a number of additional environment items to access
this information. But the one thing it doesn't do is deal with the
evalluation-agent issue.

Now, there are several ways this could be handled, and I'm open to suggestions
as to which one makes the most sense. We could:

(1) Have the imap-sieve document update the environment specification with an
    additional evaluation-agent value.

(2) Make the evaluation-agent enumeration extensible and have imap-sieve add
    a value to the list.

(3) Simply add the "store" value to the list in the existing environment
    document, along with an informative reference to imap-sieve.

(3) seems like the simplest and the least amount of work so I'm inclinced to go
with it, but I'll go with whatever consensus emerges.

> 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.

On the contrary, it would be very wrong for this to be changed. In particular,
the registration policy for environment items needs to be aligned with that for
Sieve extensions in general because it is expected that various extensions,
including but not limited to the imap-sieve one I've already mentioned, will
want to define their own environment items. If it isn't aligned  we create a
situation where some extensions can define environment items and others cannot,
which would be more than a little ridiculous.

RFC 5228 section 6.2 gives the policy for new Sieve extensions: Standards track
or experimental RFCs. Now, you may argue that experimental Sieve extensions
should not be allowed, but that ship has already sailed (and I might add it did
so during your own tenure on the IESG).

> In conclusion, I object quite strongly combining message and
> interpreter context information.  The other comments I'm making are
> less serous.  However based on the number of comments I think this
> document needs significant positive review before it is ready to be
> published.

Your assertion as to what is being combiner here is fallacious. I suggest you
reexamine what it means for something to be related to a message as opposed to
the evironment surrounding the message.

As for the number of comments being made, this is the first one I've seen that
I've viewed as anything other than editorial in nature.

				Ned
_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf