[Top] [All Lists]

Application of Mime to Netnews

1999-01-13 10:10:45
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

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


        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

        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

        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

        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-

        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,
        for "application/news-groupinfo" see, 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

        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

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

        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
        c) likewise, that any digital signature applied to it will
        survive tramsmission intact.

        The MIME content type definition of "application/news-message"

        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:
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

<Prev in Thread] Current Thread [Next in Thread>
  • Application of Mime to Netnews, Charles Lindsey <=