Eric Thomas <ERIC@FRECP11>
Thu, 16 Oct 1986 13:49 SET
|
I was going to send a piece of mail about the X-LSVOPTS tag but I decided to
read all my LSTSRV-L mail before and saw that Jose had already done that. :-)
So, when all servers have installed 1.5 the ACK option will be forwarded
without any problem. Users can set it themselves with the SET command unless
the list is Validate=All commands. The problems are:
1) Should NOACK mean no message at all, or just a single message? As I said I
myself think NOACK should mean nothing at all, but some people think other-
wise. I'll do what the majority wants.
2) Should "NOACK" be the default? Certainly not. The day I change the default
value to NOACK, I'll get tons of letters suggesting a new feature to LIST-
SERV allowing you to get a message (or possibly file, but I realize that
this would need some time to implement) acknowledgement, because when the
links are down, etc, etc. The default should be either ACK or MSGACK, and
each user will have to learn how to change it. That's pedagogical and forces
them to read the refcard. :-)
3) Should we use the Acknowledge-To: field? Not as it was mentioned; however it
could be considered that when your distribution option is still "default",
then if there is an Ack-To: field you get ACK effects while if there is no
Ack-To:, you get NOACK plus one message from the first server telling you
that you're not on the list and NOACK was assumed, or suchlike. This would
also serve as a "your mail was received". The Ack-To: just cannot override
the ack setting because it is only binary while there are three values for
the ack setting. Nothing prevents you from adding a line saying
"X-LSVOPTS: NOACK" in the mail header before sending. Good idea, I'll try
it on this piece of mail and see what happens :-)
LSVPUT: right, and I maimed the FINHUTC list because of that. Needless to say
I have fixed it. Curse me.
REView: agreed, with the restriction that if the list is confidential, you
still get rejected (LIST LONG would not show it then). So if (not authorized
to review) and (authorized to LIST) then (force the SHORT option).
SET with validate=all: right, it would not really be a security problem provi
ded I send mail back informing the sender of the change. However, this will
cause complaints that "heck, I sent a command and then it sent me a piece of
mail informing me of the command I sent!!! That's stupid!!!". Also this introdu
ces an exception in the handling of the validate=all commands keyword, which I
don't like too much. Comments?
Eric
|
|
|