I recently offered to post here the current working USEFOR draft on
Mime, and Ned Freed has asked me to go ahead and do it, so here it is.
Note that it is mostly free-standing, but there are some reliances
on other parts of the USEFOR draft that might be slightly perplexing
at first sight (notably the mention of "agencies having the proper
authority" and "matters of policy" which actually have very specific
definitions).
Observe that I have written a Health Warning around the
application/news-message bit to indicate that it (or something to
replace it) is a matter of current debate.
6.x MIME headers
6.x.1 Syntax
The following headers, as defined within [RFC-2045] and its
extensions, may be used within articles conforming to this
Document.
MIME-Version:
Content-Type:
Content-Transfer-Encoding:
Content-ID:
Content-Description:
Content-Disposition:
Content-MD5:
Insofar as the syntax for these headers, as given in [RFC-
2045], does not specify precisely where whitespace and
comments may occur (whether in the form of WS, FWS or CFWS),
the usage defined in this Document, and failing that in
[MESSFOR], and failing that in [RFC-822] MUST be followed. In
particular, there MUST NOT be any WS between a header-name and
the following colon and there MUST be a SPACE following that
colon.
The meaning of the various MIME headers is as defined in [RFC-
2045] and [RFC-2046], and in extensions registered in
accordance with [RFC-2048]. However, their usage is restricted
as described in the following sections.
6.x.2 Content-Transfer-Encoding
Posting agents SHOULD specify "Content-Transfer-Encoding:
8bit" for all articles not written in pure ASCII and not
requiring full binary. They MAY use "8bit" encoding even when
"7bit" encoding would have sufficed. They SHOULD specify
"base64" when the content type implies binary (i.e. content
intended for machine, rather than human, consumption).
NOTE: If a future extension to the MIME standards were to
provide a more compact encoding of binary suited to transport
over an 8bit channel, it could be considered as an alternative
to base64 once it had gained widespread acceptance.
Posting agents SHOULD NOT specify encoding "quoted-printable",
but reading agents MUST interpret that encoding correctly.
Encoding "binary" MUST NOT be used (except in closed networks
with alternative transport arrangements) because this Document
does not mandate a transport mechanism that could support it.
Injecting and relaying agents MUST NOT change the encoding of
articles passed to them. Gateways SHOULD ONLY change the
encoding if absolutely necessary.
6.x.3 Content-Type
There exist many content types which, whilst being technically
unexceptionable, are politically undesirable. It is therefore
anticipated that agencies having the proper authority will, as
a matter of policy, place restrictions upon the content types
to be used within particular hierarchies or particular groups.
In the absence of such explicit policies, the following
defaults are provided as an indication of current best
practice.
The Content-Type: "text/plain" is the default type for any
news article. Other text types (such as "HTML") are thus
inappropriate unless and until policy or custom has
established otherwise.
In the event that such other text types do get used then, for
the benefit of readers who see it only in its transmitted
form, the material SHOULD be "pretty-printed" so as to keep it
(including any sequences which control its layout or style)
within the recommendations and limits on line lengths set out
in section 4.6, and so as to keep such sequences, as far as is
possible, separate from the meaningful text.
Content-Types requiring special processing for their display,
such as "application", "image", "audio", "video" and
"multipart/related" are deprecated except in groups
specifically intended (by policy or custom) to include them.
Exceptionally, those application types defined in [RFC-2015]
and elsewhere for use within "multipart/signed" articles, and
the type "application/pgp-keys" (or other similar types
containing digital certificates) may be used freely.
Reading agents SHOULD NOT, unless explicitly configured
otherwise, act automatically on Application types which could
change the state of that agent (e.g. by writing or modifying
files), except in the case of those prescribed for use in
control messages (6.5).
The Content-Type "message/partial" MAY be used to split a long
news article into several smaller ones, but this usage is
deprecated on the grounds that modern transport agents should
have no difficulty in handling articles of arbitrary length.
IF this feature is used, then the "id" parameter SHOULD be in
the form of a unique message-id (but different from the
Message-ID of any of the parts). Contrary to the requirements
specified in [RFC-2046], the Transfer-Encoding SHOULD be set
to 8bit at least in each part that requires it. The second
and subsequent parts SHOULD contain References headers
referring to all the previous parts, thus enabling reading
agents with threading capabilities to present them in the
correct order. Reading agents MAY then provide a facility to
recombine the parts into a single article (but this document
does not require them to do so).
The Content-Type "message/external-body" could be apropriate
for texts which it would be uneconomic (in view of the likely
readership) to distribute to the entire network.
The Content-Type: "multipart/mixed" (also
"multipart/parallel") may be used freely in news articles.
By default, the use of the Content-Type:
"multipart/alternative" is deprecated (on account of the extra
bandwidth consumed and the difficulty of quoting in
followups).
The Content-Type: "multipart/digest" is commended for any
article composed of multiple messages more conveniently viewed
as separate entities. The "boundary" should be composed of 28
hyphens (ASCII 45) (which makes each boundary delimiter 30
hyphens, or 32 for the final one) so as to accord with current
practice for digests [RFC-1153].
[Actually, this conflicts with some present digest usage (such as the
news.answers rules), but should still be the right way to go. I
suggest this is left in for now (just to stake a claim), while we
discuss the matter with the news.answers moderators and the faq-
maintainers.]
The Content-Type: "multipart/signed" [RFC-1847, RFC-2015] is
the preferred method for the bodies of news articles that are
to be digitally signed. However, encryption (as in
"multipart/encrypted") is deprecated.
6.x.4 Character Sets
In principle, any character set may be specified in the
"charset=" parameter of a content type. However, character
sets other than "us-ascii", "iso-8859-1" (and the
corresponding parts of UTF-8) ought only to be used in
hierarchies where the language customarily used so requires
(and whose readers could be expected to possess agents capable
of displaying them).
6.x.5 Definition of some new Content-Types
This document defines (or redefines) several new Content-
Types, which require to be registered with IANA as provided
for in [RFC-2048]. For "multipart/news-groupinfo" see 6.6.1.1,
for "application/news-groupinfo" see 6.6.1.2, for
"application/news-checkgroups" see 6.6.5, and for the
remainder see this present section.
6.x.5.1 Application/news-transmission
The Content-Type "application/news-transmission" is intended
for the encapsulation of complete news articles where the
intention is that the recipient should then inject them into
Netnews. This Application type SHOULD be used when mailing
articles to moderators and to mail-to-news gateways.
[The remarks about sending articles to moderators should perhaps be
made in a more appropriate place in our standard.]
NOTE: The benefit of such encapsulation is that it removes
possible conflict between news and email headers and it
provides a convenient way of "tunnelling" a news article
through a transport medium that does not support 8bit
characters.
The MIME content type definition of "application/news-
transmission" is:
MIME type name: application
MIME subtype name: news-transmission
Required parameters: none
Optional parameters: moderate; inject; relay
Encoding considerations: A transfer-encoding (such as
Quoted-Printable or Base64) different
from that of the article transmitted
MAY be supplied (perhaps en route) to
ensure correct transmission over some
7bit transport medium.
Security considerations: A news article may be a "control
message", which could have effects on
the recipient host's system beyond
just storage of the article. However,
such control messages also occur in
normal news flow, so most hosts will
already be suitably defended against
undesired effects.
Published specification: [USEFOR]
Body part: A complete article or proto-article,
ready for injection into Netnews, or a
batch of such articles.
NOTE: It is likely that the recipient of an
"application/news-transmission" will be a specialised gateway
(e.g. a moderator's submission address) able to accept
articles with only one of the three parameter types
"moderate", "inject" and "relay", hence the reason why they
are optional, being redundant in most situations.
Nevertheless, they MAY be used to signify the originator's
intention with regard to the transmission, so removing any
possible doubt.
When the parameter "relay" is used, or implied, the body part
MAY be a batch of articles to be transmitted together, in
which case the following syntax MUST be used.
batch = 1*( batch-header article )
batch-header = "#!" SPACE "rnews" SPACE article-size CRLF
article-size = 1*digit
where the "rnews" is case-sensitive. Thus a batch is a
sequence of articles, each prefixed by a header line that
includes its size. The article-size is a decimal count of the
octets in the article, counting each CRLF as one octet
regardless of how it is actually represented.
NOTE: Despite the similarity of this format to an executable
UNIX script, it is EXTREMELY unwise to feed such a batch into
a command interpreter in anticipation of it running a command
named "rnews"; the security implications of so doing would be
disastrous.
6.x.5.2 Application/news-message
[WARNING: The application/mews-message type as described here has been
subject to much adverse criticism. Thus it is liable to be replaced by
an alternative method of encapsulation in a future draft of this
document.]
The Content-Type "application/news-message" is intended for
the encapsulation of complete news articles which have already
been posted to Netnews and which are for the information of
the recipient, and do not constitute a request to repost them.
This Message type SHOULD be used when a courtesy copy of a
followup is mailed to the author of its precursor, and when
gatewaying from news-to-mail.
NOTE: The benefits of such encapsulation are
a) that it will be apparent to the recipient that what he sees
is a copy of a news article rather than an original email;
b) that it will survive tramsmission intact even when the
transport medium does not support 8bit characters and has to
employ some special Content-Transfer-Encoding;
c) likewise, that UTF-8 characters in headers will survive
transmission;
c) likewise, that any digital signature applied to it will
survive tramsmission intact.
The MIME content type definition of "application/news-message"
is:
MIME type name: application
MIME subtype name: news-message
Required parameters: none
Optional parameters: none
Encoding considerations: A transfer-encoding (such as
Quoted-Printable or Base64) different
from that of the article transmitted
MAY be supplied (perhaps en route) to
ensure correct transmission over some
7bit transport medium.
Disposition: By default, presentation agents SHOULD
display news-messages inline, except
where overriden by a
Content-Disposition header.
Published specification: [USEFOR]
Body part: A complete news article, as already
injected into Netnews.
6.x.5.3 Message/news obsoleted
[WARNING: In view pf the possible withdrawal of the proposed
application/news-message (see above), it should not be assumed that
the obsoletion of message/news will necessarily remain in future
drafts of this document.]
The Content-Type "message/news", as previously registered with
IANA, is hereby obsoleted and should be withdrawn. The reason
is that, according to RFC-2045, it is expressly forbidden for
any "message" type to use a transfer-encoding other than
"7bit", "8bit" or "binary", thus preventing a news article
which makes full use of UTF-8 characters in its headers, or
which uses (as it SHOULD) "8bit" as its own transfer-encoding,
from being passed through a 7bit transport medium (recall that
it is not permitted by this document for the transfer-encoding
of a news article to be changed).
6.x.6 MIME within headers
Since the headers of news articles are expected to use the
UTF-8 character set, they SHOULD NOT normally be encoded using
the MIME mechanism defined in [RFC-2047]. Nevertheless,
reading agents SHOULD support that usage.
It is to be noted, however, that RFC-2047 encoding would be
required were a news article to be transmitted as a mail
message without first encapsulating it as an
"application/news-message" as suggested above.
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Web:
http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506 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