From: "Bruce Lilly" <blilly(_at_)erols(_dot_)com>
You seem to be unable to accept the fact that several people disagree
with your opinions for valid reasons (which have been patiently
explained to you). That is your problem, and you'll have to learn
to deal with it. Telling others to shut up is inflammatory,
counter-productive, and unprofessional; that creates problems
for mailing lists like this one. I suggest that you take a more
professional approach. You might also want to read RFC 3683.
Bruce, from an outsider standpoint, it is people like yourself, the Keith
Moores, etc, it is very evident to see how your antigonistic input ruins the
process of communications. You treat input as it is all nonsense opinions.
People need to go to extremes to get anything said.
I clearly stated my view of the problem and I stated a solution. You have
the right to disagree, which is fine. But to tell me I am wrong, well, that
is where it "create" problems because quite frankly, my credentials as a
software developer and product producer in this market is very much evident
over yourself. Do you think I like to say this? No. But you give no one
the benefit of the doubt. I still don't understand what make you the sage
of all that is being debate. Why does it seem it has to pass the "Bruce or
Keith" test?
The facts:
In regards to mail only, only 1 part:
o 20+ year of Mail Hosting/Communication Systems.
o One of the original developers for Offline MUA systems.
o One of the original Groupware Systems.
o Multi-Access/device Support (GUI, POP3, Telnet, Dialup, WebMail)
o Some specifics features:
- External and Local Message Conferencing
- SMTP, UUCP mail support
- Fidonet Support
- UTI, QWK, OPX and BlueWave support
- Windows Exchange Messaging Support
- List Server Support
- News Server Support
- Advance Scripting Systems for RBM (Rule Based Messaging)
- Event Signaling for all Mail Actions
- IM (Instant Messaging) Completely tied into system
etc, etc, etc.
Please note, I am not talking about those MUA designed to understand
groupware systems, such as a Newsgroup reader, IMAP or have specific
proprietary groupware concepts such as MS Exchange or Lotus Notes. Small
note: Outlook Express and Outlook are two different MUAs. OE is your common
MUA. Outlook supports conferencing with exchange interfacing. Our Wildcat!
Exchange product add-on offers our backend support for Outlook for example.
So when I provide input, I like to think I can help to provide a perspective
and insight that is based on a multi-million company long term design and
product engineering. It is not just an whimsy opinion. Now, if you can
tell me I am wrong, well, you better be ready to show me how with sound
reasons. I am not stubborn to understand where thing can be improved and
trust me, I respect good technical people.
But I am not here to fight with you. I purposely introduced myself into the
thread with due care because there is a history here (IETF wg in general)
that things get out of hand. Who was the one to begin attacking? You. Not
me Follow the thread. Just like you were argueing with everyone else, I
was sort of waiting to see when you will begin to jump on me. Keith held
his ground until he could no longer! What was his single input? "You are
wrong. Fix your program!" This is all crazy! You both failed to read
anything and picked off specific items with moronic responses that had
nothing to do with anything.
Case in point? The hilarious "MUAs are not trained!" Now I am made to feel
like I am immigrant, a terrorist of the english language! It was so
hilarious I gave up talking to you! But you had to continue attacking? Its
in your blood.
Well, lets talk about "Training."
Frankly, when you have the software engineering background I do, we do have
such "out of the box" understanding of things. Software is trained in the
sense they are moded and learn to behave in a common way understood. While
they are some good specs to work with, you still need to understand how the
ergonomics of the system is suppose to work. There is no specs on the
ergonomics. This usually means, they learn to see how others behave as
well.
In any case, that is all stupid. The point was clear:
The RFC based OFFLINE MUA does not understand mailing list concepts for two
reasons:
- They are NOT trained to understand the concept,
- The BACKEND does not have a standard to help them better work in this
area.
This is a professional design opinion which at a snap of a finger, we can
help address for our own system - the backend and our MUAs. In most cases,
it isn't issue. Here is why:
When a conference is created, the admin has the option to
- Create it as a List Server storage conference
- Expose it as a Local Online Reading conference
- Expose it as a Local Newsgroup Forum
This means that all devices may have access to the conference.
- Telnet/Dialup Console (Dump Terminals) user access
- Our free GUI user access
- Web Mail user access
- Newsgroup Reader user acess
- POP3 user access.
POP3 users will get their mail personalized from the expanded copies that
remain within the domain. They don't access the list storage conferences but
their own personal inbox.
Never mind the complexities of supporting multi-devices when it somes to the
advent of MIME mail, asyou can see, there is a bigger picture that is
considered here. The natural reply for each device must be done in a way
that is more obvious by default.
But it should go without saying the the Offline POP3 access point has done
more in the area of helping to create conflicts in system mail policies.
This debate is just one of them. I can provide you with more insight where
there needs to be more standardization for the offline EMAIL reader.
I will give you two of them:
- Receive Date:
- Honoring Server Mail Policy - the "Snoop/Preview Problem"
The above are problem the two top issues we had to deal with, more so than
this "natural reply" issue for mailing list messages.
- Receive Date:
This was done a long time ago so I can't recall off hand which MUAs exhibit
the same behavior. Outlook was one of them, but it also shows up in others
as well.
You see, an MUA like Outlook will have two date column by which they can
sort by:
Message Date: The 822.Date Header
Received Date: The 822.Received Header
The question is, what is the "actual receive date" for a message picked up
by an offline reader?
Well, if you use the Received: Date, this will be the timestamp arrived at
the MDA. Ergonomically, this date could be older than the user expected.
It could depend on the user's POP3 frequency. If you pop every minute, then
you are more likely to get a time of arrival that is closer to the user's PC
time.
But regardless, if you are looking at the new mail listing on your MUA and
you see 1-2 new messages that were arrived "2-3 hours" ago, well, it makes
some user's wonder as it did for us when it was reported as to why they are
having a hard time sorting the columns.
You see, you really can't sort by the 821.Date which they are is mixed of
messages coming from all over the place and there is the small change that
there some errors in some 821.dates. So the ideal sort column is the
receive date.
Our solution was to proivde an sysop option for the POP3 server to add a new
"Received:" header that represents the actual PICK UP time. It is off by
default.
- Honoring Server Mail Policy - the "Snoop/Preview Problem"
This one is probably the #1 conflict that one can see when dealing with
offline mail systems.
You really need to have an understanding of long established mail server
frameworks to understand the issues this introduced. Historistically, only
admins had "god powers" to snoop on mail, to preview mail without marking
the message as received/read. User's simply didn't have such power and for
good reasons. Namely the following:
- Subscription based controlled systems,
- System Notifications,
- Request Receipt Notificatons,
and other related ideas that dealt with tracking and control.
For online systems, it was all under the control of the server side.
However, with the advent of the offline mail reader, namely POP3, it
provided a new requirement to "preview mail" without marking the messages as
already received.
A good example why this because a requirement is for roaming users, who may
be on vacation or off-site to read private mail. But when they get back
home or work, they want to once again pick up the same mail.
To introduce a new violation of mail security and integrity for the backend.
Now it was possible for users to preview mail without any tracking or
recording. Now it was a possible for a system to send an "expiration notice"
and the user claiming that he never saw it. "Hey, why did you lock me out?"
To make a long story short, here, the final analysis required a revamping of
new server side features that allowed for both offline and online mail
previewing while still keeping a track of the system. So when you go to the
web mail client, you have two buttons, one with "binoculars" to preview the
message, the other to do a normal read.
Thats it for now. I will say one final thing. I have no admonisity towards
anyone. I don't know you, but I admire Keith Moore and I wish we can be more
friends than exhibit cyber agreesiveness. Maybe I am naive, but I would
like to see the IETF become a more productive in this work, especially in
the new era where change is in the "air." We are faced with a new
opportunity for change once again. Yet, we see a vast conflictive
convoluted, disjointed efforts . Much of it is clearly based on stubborn -
the old dogs don't want to change. You know what? I don't either, but I
understand and recognized when you need to progress with some changes. This
is why I began to participate in the IETF last year. In anycase, I suggest
you should learn listen to what people are saying and proposing. Give them
the benefit of the doubt because quite frankly they might be seeing an angle
of it you simply don't see. You might be set in your ways that it creates
unreasonable lack of consensus. This is what you need to learn.
See ya
--
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com