All GNKSA/U evaluations are compiled by Tim Pierce at <URL:http://http.bsd. uchicago.edu/~twpierce/news/>.
The software as reviewed fails the Good Net-Keeping Seal of Approval for Usenet Software for only one reason :
Though not required by GNKSA/U, some points could be improved :
The "Post WYSIWYG" concept may be considered not completely respected, strictly speaking. But see note 5 for more details. I consider that, as Mozilla very seriously warns users about its behaviour (in its Release Notes), the only problem which remains (no warning when rewrapping text) is negligible. The important point is that we will no longer see articles with looooooooong lines coming from Mozilla, except when the user really wants to post this way.
One debatable point : Netscape may be configured for choosing to send either Quoted-Printable (several people call this Quoted-Unreadable) or 8-bit characters. The default is 8-bit which is correct, IMHO (several hierarchies outside the Big-7 seem to agree for encouraging 8-bit characters use). Unfortunately, the QP/8-bit is for both mail and news in Netscape. As using QP is often the only way to properly send 8-bit characters in mail messages (due to old MTA implementations), this often leads to many QP sending in news. I think that QP/8-bit should be made independent in News and Mail (other think that QP posting should be completely prohibited....:-)).
Another point not covered by GNKSA/U : Netscape is known for a very famous bug : the multiposting of serveral copies of news articles by Netscape users, very often through modem dialup links. Jamie Zawinski (from Netscape Corp) recently (around June 1996) posted a detailed explanation about this problem (Jamie, if you still have a copy of your post, I think it would be interesting to add it to this evaluation as a footnote). Though the Post button is disabled during the communication between the news server and Netscape 2.0+ while sending an article, it is likely that the problem sometimes still occurs. According to Mr Zawinski (see note 6), this comes from the slow acknoledgment problems from news servers (I resume here : please refer to jwz original post) and they tried in version 3.0 releases to fix this problem when it still occurs. As I conduct my evaluation tests with a local news server, I cannot test this. I may only speak of my own and recent experience : I haven't actually seen any multiple post articles coming from Netscape 3.0 series. It is likely that this problem may be considered as fixed......
This software may be found at <URL:http://www.netscape.com>.
Below is the detailed evaluation checklist :
Req Itm Sub- Item rd? ## Description item OK? OK? Notes Y 1 Display all essential header info YES Y default is to display YES Y a) display author YES Y b) display subject YES Y c) display newsgroups list YES Y d) display Followup-To list YES Y e) display Reply-To if /= From: YES Y 2 Provide standard commands YES Y clear YES Y separate YES Y a) post a new article YES Y b) post a followup article YES Y c) reply by email YES N use standard terminology NO 1) Y 3 Implement cross-posting YES Y allow user specification YES Y cross-post (not multi-post) YES Y 4 Change essential headers YES Y change headers while editing body YES Y change Subject YES Y allow at least 70 chars in subject YES Y change Newsgroups YES Y change Followup-To YES Y allow followup-to: poster YES Y change Reply-To YES Y 5 Correct Subject headers in flwup/rply YES Y a) prepend "Re: " (exactly!) YES Y b) preserve entire Subject YES Y even subjects > 80 chars long YES Y 6 Respect Followup-To YES Y use to initialize Newsgroups: in flwup YES Y recognize and act on 'poster' YES Y 7 Followups contain References YES Y contains message-id of original YES Y never truncate individual message-id YES N contains three Refs from original YES N contains entire Refs of original YES Y 8 Direct email reply to Reply-To YES Y 9 Quotation and attribution YES Y provide method YES Y set off by prepend YES Y attribution line YES Y identifies author YES 2) N gives message-id NO Y 10 Subject is mandatory YES Y do not post empty or provide <none> YES Y allow change while editing body YES Y 11 Must provide valid From: header NO Y syntactically valid NO 3) N belongs to the user NO 4) Y 12 Must provide cancel YES Y of own articles YES Y *not* of others YES N 13 Respect line length, and post WYSIWYG NO N line brks shown are present when posted NO 5) N do *not* post paragraph w/o line brks YES N warn if body has lines > 80 chars YES N external editor conforms N/A N 14 Prevent obvious errors YES N prevent posting empty article YES N prevent posting only quoted text YES
First a short description of what the columns in this checklist stand for:
Standard terminology Button text Menu item --------------------------------------------------- Post (new message) To: News New News Message Followup Re: News Post Reply Reply (by mail) Re: Mail Mail Reply
-------------------From Mozilla 3.0b5 release notes : begin--------------------------------------------
Message Composition Improvements
The message composition window contains a text area in which the user edits their mail messages. This window has the dual responsibilities of making it easy and comfortable for the user to edit the text of their messages; and also to deliver those messages to their recipients in a readable, standard-compliant form. With this release, we have made some changes to how that is accomplished.
Word wrapping occurs at 72 columns, regardless of window width.
First, some background on the issue: when a plain-text message is sent out over internet mail or news, it must have relatively short lines: that is, the standard for interchange of text/plain messages is that they should be preformatted for display on 80-column fixed-width displays (because that is the greatest common denominator with which participants in internet mail and news can assume universal interoperability.)
That, however, is the description of a format: how the data must be transmitted ``on the wire.'' It doesn't necessarily have anything to do with the user interface. To give our users the most comfortable editing environment, we allow them to use a normal, word-wrapping text area for message composition; and then when the message is sent, we wrap the lines in that text so that a standards-compliant message is delivered.
In this release, the method by which word-wrapping happens has been subtly changed.
In previous versions, we wrapped the long lines at the width of the window: this gave a What You See Is What You Get aspect to the message composition window: regardless of whether the user had allowed their text to auto-wrap, or had hit return at the end of every line, or had resized the window, what the recipient of the message would see would have had the same line breaks that the originator of the message saw on their screen. Thus, there wouldn't have been any surprises.
The problem with this was that many people didn't realize that this was happening, and consequently made their composition windows very wide for ease of editing. The result of this was that it was very easy to accidentally send out messages with long lines that exceeded the 80 column limit. To many recipients, such messages would be very difficult to read.
In this version, we wrap outgoing text at 72 columns, regardless of the size of the window.
This makes the composition window less WYSIWYG, in that the exact line wrapping that the author sees won't necessarily be the same line wrapping that the recipient sees; but it does make it much harder to accidentally generate unreadable messages, while still making message composition relatively uncomplicated.
There is (and has been) a single exception to the line wrapping rule, which is that lines which have the character > as their first character are never wrapped: the assumption here is that such lines are a part of quoted text, and it is very important to avoid generating messages which look like this:
> All work and no play makes Jack a dull boy. All work and
no play makes
> Jack a dull boy. All work and no play makes Jack a dull
boy. All work
> and no play makes Jack a dull boy. All work and no play
makes Jack a
> dull boy. All work and no play makes Jack a dull boy.
So in this case, by not wrapping the lines, we allow quoted text like that to exceed the usual 72-column limit, under the assumption that in this case, lines that are slightly too long are easier to read than lines that are inappropriately wrapped.
This was done in previous versions, and it's still done today.
However, it is also still true that lines beginning with > will appear to be wrapped in the composition window if the lines are longer than the window is wide; this is an unavoidable property of the platform-provided text editors that we use. It is at the time the message is sent that these lines will be effectively ``un-wrapped.''
There is an option to turn off all word-wrapping.
Since the column at which word-wrapping occurs is no longer tied to the size of the window, we have added an option to turn off word-wrapping on the compose window altogether. This is for use in the less common case where one needs to send a message with specially-formatted text; for example, wide tables or charts, or data where wrapping the lines would damage the data.
When this option is selected, two things happen: first, the text area no longer does word wrapping (a horizontal scrollbar will be presented instead); and second, the generated message will have exactly the line breaks that the user inserted explicitly: no automatic wrapping of any kind will occur.
The option which controls line wrapping may be found on the View menu of the message composition window. The default for this option is to wrap lines, and this option is not persistent: if one turns wrapping off, that only affects this particular composition window this one time. The reason for this is that ``no wrapping'' is an unusual case: if one is composing text, or a normal message reply, one generally wants wrapping. But occasionally, one needs to send specially-formatted data, and that is what this option supports.
-------------------From Mozilla 3.0b5 release notes : end--------------------------------------------
Message-ID:
<318923FF.5656@netscape.com>
Date: Thu, 02 May 1996 14:07:11 -0700
From: Jamie Zawinski <jwz@netscape.com>
Organization: Netscape Communications Corporation, Mozilla Division
X-Mailer: Mozilla 3.0b4 (X11; U; IRIX 5.3 IP22)
MIME-Version: 1.0
Newsgroups: comp.infosystems.www.browsers.misc,news.software.readers
Subject: Re: What's this 'Mozilla' trash anyway?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
John E. Davis wrote:
>
> I have not done it yet but I have thought about it. Whenever I see 3
> identical posts I check the headers and I almost always see the word
> `Mozilla' somewhere. It is at that point that I contemplate killing all
> Mozilla posts. The only thing that has prevented me from doing
> this is the lack of the appropriate header in the overview database.
>
> Accidentally posting identical articles should be easy to prevent.
Well, it boils down to "user error", but there are a few things that
Mozilla (aka Netscape Navigator) used to do that made it an easier error
for users to make.
In betas before the final 2.0 release, including 1.0 and 1.1, when
you hit the "Send" button on a mail/news composition window, the
button
stayed active -- and if you managed to accidentally hit it again before
the delivery had completed and the window had popped down, it would send
it again.
Before 2.0, it was not uncommon for people to accidentally double-click
and generate duplicates that way. In 2.0 and newer, this part of the
problem is fixed by making all buttons except the "Stop" button
gray out
as soon as delivery starts; to interupt that delivery and start delivery
again, you have to hit the stop button, then hit the send button again;
so it's not possible to do it by a simple finger-fumble.
Now, there's another problem here that's a bit harder to address.
News delivery works like this:
1: connect to NNTP server;
2: send the POST command;
3: wait for a reply (to see whether posting is currently allowed);
4: send each line of the message;
5: send the "end of message" indicator ("." alone on a
line);
6: wait for reply (confirmation of the post, or error rejection).
You'll notice that there's something of a race condition here between
steps 5 and 6: if the user hits "stop" at that point, we don't yet
know
whether the server has accepted the message. It *probably* has, since
we have sent all the data we have to send; but it hasn't responded yet.
So we don't know if, were we to "hang up", whether the message
would be
sent or not.
This is compounded by the fact that the point between steps 5 and 6 is a
common place for INN (or its underlying inews, or something) to go off
into space for a long time, without giving any feedback. I'm not sure
why this happens, perhaps it's a result of the server being
miconfigured, or perhaps it only happens when the server is heavily
loaded, or when "expire" is running; but the fact is, there is often a
delay there at many sites, sometimes a long one.
So, users see this and think, "it must be wedged. I'll try again."
And they hit stop, and hit send, and now there are *two* copies in
the pipe (both stuck in the same way). Whereas if they had just
iconified the window, it would have completed the post normally
eventually (but maybe 15 minutes later, depending on how hosed the
NNTP server was...)
In later versions of Netscape (post 2.0, that is, 3.0b1 and newer, aka
"Atlas") we have tried to improve this by adding more feedback on the
composition window -- the "thermometer" will actually show how much of
the message has been sent; and when it reaches step 5, the message area
says "Message sent; waiting for reply..."
Another way we tried to avoid these duplicate posts is by making sure
that if the user hits "send" a second time on the same composition
window (without an intervening edit of the text) that we use the same
message ID for the message we attempt to send -- and since the NNTP spec
demands unique message IDs, if somehow the same message gets injected
into the NNTP stream twice, the NNTP server will throw one of the
duplicates away before anyone sees it. (Actually what we do is a little
bit more complicated/clever than this, but that's the gist of it.)
Most other news posting software sidesteps these problems by simply
locking the user interface solid until the post has completed; but we
didn't want to do that...
So, the bottom line is, you should see fewer duplicate posts coming from
Mozilla 2.0 than from earlier releases, and fewer still from 3.0.
--
Jamie Zawinski jwz@netscape.com http://www.netscape.com/people/jwz/
``A signature isn't a return address, it is the ASCII equivalent of a
black velvet clown painting; it's a rectangle of carets surrounding
a quote from a literary giant of weeniedom like Heinlein or Dr. Who.''
-- Chris Maeda