Okey, I'm really not a typical user, I'm far too much of a techie for
that. But I'll try anyway to play the role, grabbing the hat of a
typical message enabled user, so to speak. It will have some connections
to the good points Steve was bringing forward.
A clarification: I am trying here to express user requirements, not
technical requirements. I thought it might be useful to inject an end
user's perspective into this discussion.
And, I'm quite aware of the fact that all the requirements expressed
below can't be addressed in a work group to-be. Never the less, I think
it's good to have them in mind when designing selective parts.
[User Hat On]
As a typical user, not knowing much about the technology behind my
favorite tools, I have a need to feel like being in control of my
messages without knowing about technicalities. Therefore, when it comes
to message filtering, an acceptable solution should allow me to:
1. Control the flow of my messages in a non-technical and intuitive way.
2. Communicate my control requirements in an interoperable way,
independent of which favorite tool I use and independent of which
favorite service provider I choose.
3. Feel confident that my authority is not compromized.
4. Have access to comprehensive status and activity reports so I can
determine whether my control requirements are met or not.
5. Understand when and why actions are taking place.
Not very likely, but I might also need to understand the relation
between my control requirements, the rules that is set to implement
them, and the performed actions that affect the flow of my messages.
I expressed the user requirements above in a non technical language on
purpose (except for the words rule and action maybe). Also, as a user I
don't want to enter rules directly. That sort of hack is for power
users, which is not my hat. On the contrary, I want to work message and
address oriented, making my intention clear by giving examples of what I
want to do on what criterias.
A short note on the list of requirements above.
Regarding requirement 1: It implies that my tool is powerful enough to
allow me to give commands like (for example):
a) Subscibe to this list and put it's submissions under this label
(folder).
b) Detect messages which have this address as receiver (i.e. webmaster)
and put it under this label.
c) This is junkmail. Take it and all alikes and ditch them.
d) I'll be away for a week, so make sure all senders of incoming
messages receives a notice (only one please) and make an exception
for list exploders, please.
e) This is information I receive regularly. Make sure I share it with
my buddy next door from now on.
These are all true agent directions. They are all rules, but expressed
in a (for me) comprehensive language. Remember, I'm still wearing that
user hat :-) Anyway, I'm not imagining that we are going to address this
requirement explicitly. Let's have it in mind though.
Regarding requirement 2: This is the most important one, IMO. I really
hope we can reach consensus on at least what to recommend.
Regarding requirement 3: The security aspect. Have to be addressed.
Regarding requirement 4: This is the second most important one, once
again IMO. It's all about reliability and predictability and giving the
user a feeling of being in control of the situation.
Regarding requirement 5: Okay, similar to 4, except that this one is on
the borderline to power user requirements.
[User Hat Off]
My technical interpretation of the above is much about what Steve
already have been giving words for. Management and being in control.
Part from defining a common language, I think it will be necessary for
us to define what technical requirements are needed to satisfy user
requirements on the overall process of giving users control over remote
"on-behalf" actions.
Defining MDA is a good start. Now we have an entity which can,
implementation dependent of course, be completely separate to the MTA.
As a matter of fact, we can not ignore the possibility of having
arbitrary agents talking IMAP, performing post delivery filtering on
behalf of the user. Those should be controlled in a similar way.
In any case, MUA and MDA have to establish a two way communication in a
secure and reliable way. Not saying how at this time, it has to be said
sooner or later, in order to meet certain user requirements.
In my own words,
Tomas
--
Tomas Fasth
mailto:tomas(_dot_)fasth(_at_)euronetics(_dot_)com
EuroNetics Operation http://euronetics.com
Mjärdevi Science Park Office tel: +46 13 218 181
Teknikringen 1 E Office fax: +46 13 218 182
58330 Linköping Mobile tel: +46 708 870 957
Sweden Mobile fax: +46 708 870 258