To Do...

This page contains a list of items that are scheduled to be addressed by the GNKSA. Before going into detail, the reader should note that major work is being done currently on a more up-to-date RFC on Usenet issues: USEFOR. This, of course, will have a considerable impact on the GNKSA.

Because of the desirability of having a reasonably stable set of requirements, changes are not made to the GNKSA lightly. At some point in the near future, USEFOR will arrive; until then, expect changes only when really necessary.

• Use of incorrect addresses RFC 2606 prescribes marking addresses that are known to be non-deliverable by appending `.invalid'. The GNKSA would do well to reflect this:

  • Appending `.invalid' is mandatory when using a so-called `spamblock' from-address:

            When knowingly using an invalid mail addresses, it MUST be
            clearly marked as such by appending `.invalid'.

  • When replying, the user should be alerted when detecting a non-deliverable reply address:

            Addresses marked as invalid (ending with .invalid) SHOULD be
            detected and brought to the user's attention when replying to a
            message.

• Sending mail copies of followups There is an (already widely supported) proposed mechanism that allows users to indicate whether or not they do or do not wish to receive mail copies of followups to their postings. When following up to a message, such indications should (must?) be respected.

  The header in question is Mail-Copies-To; if its content is nobody (an early form used never), then no mail copy should (must?) be sent along with the followup. If the header contains poster (earlier always has also been used), a followup is requested, and should (must?) be sent to the regular reply address. A third form exists: if the Mail-Copies-To header contains a (valid) Internet mail address, a copy is requested on followups, to be sent to the indicated address:

          When following up to an article containing a `Mail-Copies-To'
          header, the indication in that header SHOULD (MUST?) be
          respected:
             - `nobody':       Mail copies are unwanted.  Don't.
             - `poster':       A mail copy is requested. Do.
             - a mail address: A mail copy is requested.  Send to
                               the indicated address.

• Notifications in mail copies In the context of the USEFOR project, the issue of "mixed-mode" messages has received some attention. This has resulted in a proposal, that is gaining more and more support, for a `Posted-And-Mailed' header. Using this header, messages can be marked as mail copies, so client software can treat it accordingly (and help prevent mistaking it for a personal mail message instead of a mail copy of a Usenet followup). Already it is a Good Thing[tm] for current newsreaders to set this proposed header when sending mail copies of postings, and for mailers to recognize such articles and deal sensibly with them (i.e. alert the user to the fact when replying, and so on).

  Additionally, when the `Posted-And-Mail' header becomes widely supported, the need to include a warning notification in the body of the mail copy itself is removed; at that point in time, the GNKSA will need to be altered to do justice to the improvement in this area.

• Character set consistency The MIME standard contains facilities for relieving the problems caused by the limitations in ANSI X.3.4 (a.k.a. `US ASCII'): mix-and-match problems of language- and platform-specific encodings, and so on. The following snippet was supplied by Markus Kuhn:

          Performs charset consistency checks:
  
          - Discourages users from posting text messages that contain
            non-ASCII characters (> 0x7e) but lack a MIME header that
            indicates the character set.
  
          - Discourages users from posting text messages that contain
            bytes in the C1 range (0x80-0x9f) with a MIME header that
            indicates an ISO 8859-* encoding. (Note: The presence of
            0x80-9f bytes usually suggests that a charset such as
            Windows CP1252 or UTF-8 was used, which should be indicated
            accurately. ISO 8859 charsets do not and will never have any
            characters in this range.)
  
          - Discourage users from posting text messages that contain the
            header line "Content-type: text/plain; charset=UTF-8" but
            contain incorrect UTF-8 byte sequences.

  Note that significant improvements in this area are expected; still, the need to deal with these issues sensibly within the bounds of the current standards (and currently used software) is strong.

Don't hesitate letting me know of your pet peeves; any reasonable request stands a good chance of making this list, and - who knows? - the GNKSA, at some point.

GNKSA Home

Brought to you by <js@gnksa.org>.
Last modification: Wed Feb 14 2001 by JS.