Andrew Akehurst
<A(_dot_)D(_dot_)Akehurst-99(_at_)student(_dot_)lboro(_dot_)ac(_dot_)uk> wrote:
In other words, the use cases there will need to be split into each
method that a user currently has available for delivering a message
appropriate to that use case.
I think I understand what you mean, but could you perhaps give a more
specific example?
My take on it is that your document talks about what the users do,
and what their intentions are. I'm a protocol guy, so I don't have
access to the users intentions. Therefore, the diagrams I need are
diagrams of network boxes, and the protocols they use to interact.
That is, machines on the network don't see intentions. They see data.
When "bob" sends "alice" email, he may do so through any number of
methods. Roaming, webmail, ISP, vpn, etc. All of those scenarios
have the same intentions, but they also have drastically different
implementation diagrams.
I had considered rewriting the document in the form of a table whose columns
represent different aspects of the scenario and whose rows correspond to
each scenario, e.g.:
Sender address | Recipient address | Forwarding? | Mailing list?
----------------------------------------------------------------
alice(_at_)a(_dot_)com | bob(_at_)b(_dot_)com | No | No
alice(_at_)a(_dot_)com | bob(_at_)b(_dot_)com | Yes, by Bob | No
Again, you're focussing on intentions. This makes it difficult to
figure out what to do. It also makes it difficult to talk about it on
the list, as the situations are wide-open for personal
interpretation. "Well, MY mailing list works, and YOURS doesn't, so I
don't see why you would want to change anything..."
Keeping things on a protocol level means that personal issues are
largely avoided. It also means that you have something concrete to
talk about: "Box A talks to box B, using protocol C, which has fields
D, E, and F, used to send messages. Field F can be forged
undetectably, so we propose solution G to address that forgery..."
In contrast, a "mailing list" means many different things to
different people. Such lists are implemented and configured
differently, all due to the intentions of the administrator. This
means that no one can agree on the definition of a "mailing list", as
everyone uses them in slightly different manners.
Alan DeKok.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg