From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Fri Jul 26 2002 - 09:04:34 CDT
Following the discussions a few weeks back about whether submissions to
moderators should be sent "encapsulated" within an email, or should be
sent as the email itself (and in that case what to do about non-ASCII
newsgroup-names), here is what Usefor has come up with.
See www.landfield.com/usefor/drafts/
draft-ietf-usefor-article-07.02.unpaged for the full gory details (that
draft, or something pretty close to it, will likely become a full
internet-draft within the next few days).
Essentially, the draft recognises two methods of sending to a moderator:
! (a) The complete article is encapsulated (headers and all) within
! the email, preferably using the Content-Type
! "application/news-transmission" (6.21.6.1). This method has
! the advantage of removing any possible conflict between
! Netnews and Email headers, or of changes to those headers
! during transport through email (and in particular, it ensures
! that any UTF8-xtra-chars within those headers will pass
! safely through any email transport even if it is 8bit-
! unsafe).
! (b) The article is sent as an email as it stands, with the
! addition of such extra headers (e.g. a To-header) as are
! necessary for an email. Since the article is, in effect,
! being gatewayed into Email, the provisions of section 8.8.1
! apply. In particular, if the headers contain any UTF8-xtra-
! chars, it may be necessary to apply encodings, specifically
! the encoding defined in section 5.5.2 in the case of the
! article's Newsgroups- and Followup-To-headers.
! Although both of these methods have seen use in the past, the
! preponderance of current usage on Usenet has been for method (b)
! and many moderators are ill-prepared to deal with method (a).
! Therefore, method (a) SHOULD NOT be used until such time as the
! majority of moderators are able to accept it.
That carefully sidesteps the issue of which method is preferred for the
long term (the marketplace will eventually settle that), whilst making
it clear that nethod (b) is to be preferred for the immediate future.
BUT, it also says, further down
! Articles will be received by the moderator either encapsulated as an
! object of Content-Type application/news-transmission (8.2.2) (or
! possibly encapsulated but without an explicit Content-Type-header),
! or else directly as an email already containing all the headers
! appropriate for a Netnews article (see 8.2.2) in which case he needs
! to be aware of the Duties of an Incoming Gateway (8.8.2) (and, in
! particular, he SHOULD adopt the Message-ID- and Date-headers of the
! email message, though he SHOULD NOT add any Sender-header).
! Moderators SHOULD be prepared to accept articles in either format.
However, we are fully aware that saying "Moderators SHOULD" is not
the same as saying that "Moderators WILL". Time will tell, but at the
least those words should ensure that people who write general purpose
moderbots such as STUMP do it correctly.
That leaves the question of what to do about non-ASCII newsgroup-names
(whether these arise as the moderated group in question, or whether they
arise incidentally as crossposts). There are three choices here:
1. Encapsulate it (but we just said that is a Bad Thing, certainly for
the short term).
2. "Just send it". We know that many mail systems will actually pass the
full 8 bits, even in headers, so this will often work (but is likely to
break as soon as a sendmail system is encountered). Now we can hardly
recommend, in an internet standard, that people should deliberately
break another internet standard, but we can (and do) point out that it
may very will work. It is really up to the writers of injecting agents,
since it is their responsibility to mail it to the moderator, and if
they think they can get away with it - well it is their problem if it
doesn't work.
3. Encode the newsgroup-name. So we have designed a special encoding for
just this purpose. Essentially, the group "dk.test.utf8-זרו.moderated"
would be encoded as "dk.test.utf8-%c3%a6%c3%b8%c3%a5.moderated" (which
just happens to be consistent with the way a News URL referring to that
group might be encoded according to RFC 2396, though our spec ensures
that the encoding of any newsgroup-name is unique).
Now normal MUAs will not decode that automatically, so some moderators
will see it in that form. But at least it will be immediately clear
to them that it is an odd case, and it is not hard to decode by hand.
However, it MUST then be decoded before the article is posted (because
we do not allow that form 'on the wire' in Usenet itself). But even here
help is at hand, because we also suggest that injecting agents MAY
do that decoding automatically (as opposed to rejecting the article
entirely). Again, it is up to the marketplace whether or not injecting
agents get upgraded to do that task.
But now that we have that unique encoding, it also solves the problem
of forming the moderators' submission address for moderators.isc.org
(since we may have to wait for ever before the mail people come up
with an official means of dealing with Non-ASCII local-parts in email
addresses). Therefore, we say that the correct way to submit articles to
that group is to mail them to
dk-test-utf8-%c3%a6%c3%b8%c3%a5-moderated@forwardingagent.example
(where "forwardingagent.example" is obviously "moderators.isc.org", but we don't
say that explicitly because our draft takes great care not to bless one cabal
over any other cabal - indeed our draft contains those famous words "There is no
cabal").
But the upshot of all this is that present arrangements for moderation
will continue to work. The introduction of Non-ACCII newsgroup names is
not going to happen overnight. They will gradually start to appear and,
hopefully, the timescale will allow agents that need to be aware of them
to keep up.
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl@clw.cs.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5