Basically, we have aliases for our convenience, so that we do not end up
typing a huge number of mail-ids.
When we have to do a similar thing to a set of users wherein there is a
superset alias available then the user is actually unable to use the
superset alias and send it out to the subset. Now usage wise, every user
can have a small example that could be absolutely of no significance to
the other. So the idea of this draft needs to be seen more as an
individualistic usage, though the importance of its usage is very
personal and no other can do any sort of evaluation of the need this has
to the other person.
Yes, this would have a few implimentational issues that the user would
face. Again the idea is not to force this feature on anybody but allow
it as an option to anybody who wants to use it. Encrypting each message
in every hop is similar. Nobody is enforcing anybody to encrypt every
message. If and only if the organization wants this feature then there
has to be proper care taken in every mail hop that the feature is
available. Thinking on similar lines, if an organization wants to use
this feature then its the responsibility of the administrator to mandate
appropriate MUA's and MTA's. This is very possible within an
organization / a small company etc. So the basic idea is, so if somebody
is very interested to use this feature, then there has to be a provision
for it. The problems that might have to be addressed have also been
mentioned in the document for the areas wherein the adman has to take
care to ensure he/she has done everything to have this feature.
Bruce Lilly wrote:
On Thu April 14 2005 08:06, Arun Sankar wrote:
Yes there are utilities to this draft.
I have a few examples to explain the utilities,
In a company, a team of say 20 there could be 2 contracters who should
not be given the details that are to be passed to the other 18, some
company confidential data. Everytime there is something confidentail,
there needs to be an individualistic mail-ids need to be typed and sent
across.
The appropriate solution to that "problem" is to have a separate list
for confidential information distribution. Any organization that has
given a moment's thought to security/confidentiality considerations
has already addressed that situation. Under your scheme, real damage
can occur if some sender forgets to exclude somebody who should not
see confidential information, and/or if *any* component of message
composition, transport, or delivery fails to adopt the sweeping changes
proposed.
It could be
something as serious as this to something as simple yet important of
sending a surprise birthday party mail to an alias of friends but just
want to neglect only the important person who is celebrating his/her b'day.
An appropriate solution to this unusual (once-in-a-while) "problem" would
be to simply send the message to the desired recipients rather than use
a list expander. SMTP explicitly provides for sending to multiple
recipients (no extensions necessary, no changes to UAs, MTAs, etc.).
Your scheme would require massive changes to the entire installed base
of MUAs, MSAs, MTAs, and MDAs to be usable, and that's a huge overhead
for such an issue that arises only occasionally.
There could be innumerable situations, simple and complex wherein there
needs to be a negation that is necesasry to help the user in making a
few matters simplified.
More wishy-washy unclear hand-waving. You have still not produced a
single compelling example.
Perhaps I wasn't sufficiently clear in my initial comments on the draft;
the underlying problem with all of the defects of the draft appears to
be that the author has not given due consideration to the issues as well
as to the procedures and policies. I apologize for being unclear. I
suggest that the author should carefully consider the documents to which
he has been referred and the comments made here and elsewhere, and then
carefully deliberate whether or not there is in fact a real "problem"
in search of a solution and if so what backwards compatible solutions
might be appropriate, or whether the proposal is a putative "solution"
in search of a nonexistent problem.
--
Arun
Optimism:
"Sir, we're surrounded!"
"Excellent. We can attack in any direction!" --An Army Officer