From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Wed Jul 24 2002 - 11:47:38 CDT
I have now put up a new draft at
http://www.landfield.com/usefor/draft-ietf-usefor-article-07.02.unpaged
This incorporates all the recent discussions regarding funny charsets in
headers, and sending stuff to moderators. Also various minor things that
arose from the Last Last Call.
There may still be a few wording changes arising from the recent
moderator changes, but I thjought it best that you should have a new
full draft in order to appreciate fully the changes we have just made.
Apart from such niggles, this is definitely a candidate for the next
(and hopefully final) internet draft, and so this is a Last Internal
Call. Note that I do not really want to enter into discussions about
other than the latest changes, because we already covered those in the
previous Last Last Call.
I now intend to summarize the changes we have made on the moderators'
list.
Here are the full diffs.
*** draft-ietf-usefor-article-07.01.unpaged Fri May 31 11:47:53 2002
--- draft-ietf-usefor-article-07.02.unpaged Wed Jul 24 17:10:18 2002
***************
*** 3,5 ****
Usenet Format Working Group University of Manchester
! June 2002
--- 3,5 ----
Usenet Format Working Group University of Manchester
! July 2002
***************
*** 6,8 ****
News Article Format
! <draft-ietf-usefor-article-07.txt>
--- 6,8 ----
News Article Format
! <draft-ietf-usefor-article-07.02.txt>
***************
*** 114,116 ****
5.5. Newsgroups ................................................ 0
! 5.5.1. Forbidden newsgroup names ............................. 0
5.6. Path ...................................................... 0
--- 114,117 ----
5.5. Newsgroups ................................................ 0
! 5.5.1. Forbidden newsgroup-names ............................. 0
! 5.5.2. Encoded newsgroup-names ............................... 0
5.6. Path ...................................................... 0
***************
*** 381,382 ****
--- 382,387 ----
+ An (email) "address" is the mailbox [RFC 2822] (or more particularly
+ the addr-spec within that mailbox) which directs the delivery of an
+ email to its intended recipient, who is said to "own" that address.
+
An article's "reply address" is the address to which mailed replies
***************
*** 541,544 ****
characters [RFC 2279] to appear in certain contexts (the five rules
! begining with "strict-" reflect the corresponding original rules from
! [RFC 2822]).
--- 542,545 ----
characters [RFC 2279] to appear in certain contexts (the five rules
! beginning with "strict-" reflect the corresponding original rules
! from [RFC 2822]).
***************
*** 599,603 ****
surrogate use in the UTF-16 encoding. These sequences MUST NOT be
! generated by posting agents. Where they occur inadadvertently, they
! MAY be passed on untouched by other agents, but they MUST NOT ever be
! decoded or otherwise interpreted as meaningful characters.
--- 600,606 ----
surrogate use in the UTF-16 encoding. These sequences MUST NOT be
! generated by posting agents. Where they occur inadvertently, they
! SHOULD be passed on untouched by other agents, but attempts to
! interpret them as malformed UTF-8 MUST NOT be made. However, if there
! is reason to suppose they are representations of some other character
! set they MAY, as suggested in section 4.4.1, be interpreted as such.
***************
*** 681,682 ****
--- 684,687 ----
Again, as in [RFC 2822], strings of characters that include
***************
*** 729,731 ****
particular, the use of non-ASCII newsgroup-names).
! o Large parts of MIME are recognised as an integral part of
Netnews.
--- 734,736 ----
particular, the use of non-ASCII newsgroup-names).
! o Large parts of MIME are recognized as an integral part of
Netnews.
***************
*** 965,968 ****
and also so as to avoid some minor parsing problems with
! addresses).
Each header-specific MIME-style parameter introduced in this standard
--- 972,977 ----
and also so as to avoid some minor parsing problems with
! <address>es).
Each header-specific MIME-style parameter introduced in this standard
***************
*** 1068,1070 ****
A comment is normally used to provide some human readable
! informational text, except at the end of an address which contains no
phrase, as in
--- 1078,1080 ----
A comment is normally used to provide some human readable
! informational text, except at the end of a mailbox which contains no
phrase, as in
***************
*** 1076,1078 ****
reading agents SHOULD take special note of such comments as
! indicating the name of the person whose address it is. In all other
situations a comment is semantically interpreted as a single SP.
--- 1086,1088 ----
reading agents SHOULD take special note of such comments as
! indicating the name of the person whose mailbox it is. In all other
situations a comment is semantically interpreted as a single SP.
***************
*** 1181,1183 ****
article was probably generated by a buggy news reader" has
! traditionally been used is this situation.
--- 1191,1193 ----
article was probably generated by a buggy news reader" has
! traditionally been used in this situation.
***************
*** 1357,1359 ****
domains and path-identities - MUST be in US-ASCII. Comments, phrases
! (as in addresses) and unstructured headers (such as the Subject-,
Organization- and Summary-headers) MAY use the full range of UTF-8
--- 1364,1366 ----
domains and path-identities - MUST be in US-ASCII. Comments, phrases
! (as in mailboxes) and unstructured headers (such as the Subject-,
Organization- and Summary-headers) MAY use the full range of UTF-8
***************
*** 1377,1399 ****
In the particular case of newsgroup-names (see 5.5) there are more
! stringent requirements regarding the use of UTF-8 and Unicode.
! Where the use of non-ASCII characters, encoded in UTF-8, is permitted
! as above, they MAY also be encoded using the MIME mechanism defined
! in [RFC 2047], but this usage is deprecated within news articles
! (even though it is required in email messages) since it is less
! legible in older reading agents which support neither it nor UTF-8.
! Nevertheless, reading agents SHOULD support this usage, but only in
! those contexts explicitly mentioned in [RFC 2047].
! Similar considerations apply to non-ASCII characters within the
! values of parameters (which, according to the syntax, MUST be in the
! form of quoted-strings in order for UTF8-xtra-chars to be
! accomodated). Such values MAY be encoded using the MIME mechanism
! defined in [RFC 2231], but this usage is deprecated within news
! articles (even though it is required in email messages) since it is
! less legible in older reading agents which support neither it nor
! UTF-8. Nevertheless, reading agents SHOULD support this usage.
4.4.2. Character Sets within Article Bodies
--- 1384,1430 ----
In the particular case of newsgroup-names (see 5.5) there are more
! stringent requirements regarding the normalization and other usages
! of Unicode.
+ Where the use of non-ASCII characters is permitted as above, they MAY
+ be encoded in UTF-8 and they MAY be encoded using the MIME mechanisms
+ defined in [RFC 2047] and [RFC 2231], but only in those contexts
+ explicitly mentioned in those documents (unstructured headers,
+ phrases and comments in the one, quoted-strings within parameters in
+ the other).
+ Encoding by other means is not compliant with this standard.
+ Nevertheless, encoding using other character sets (with no indication
+ of which one beyond the user's ability to guess based upon other
+ clues in the article, or custom within the newsgroup) has been in use
+ in some hierarchies, and such usage may be expected to continue for
+ some period after the introduction of this standard. Reading agents
+ MUST support the use of UTF-8, [RFC 2047] and [RFC 2231] in headers
+ and they MAY, when it is detected that none of these has been used,
+ attempt to interpet the header according to whatever other character
+ set can be deduced, or has been configued as a default by the reader.
! NOTE: It is possible to determine, with a high degree of
! accuracy, when a given text containing octets with the 8th bit
! set was not encoded using UTF-8, and using this test to recover
! such non-compliant texts is therefore commended where no other
! harm could arise.
! Exceptionally, Newsgroups-headers (5.5) MUST use UTF-8 in order to
! ensure that they appear in their canonical form (in any case, a
! Newsgroups-header is not one of the acceptable contexts of [RFC
! 2047]). Certain exceptions to this rule are provided (8.7 and 8.8.1)
! for use when mailing to moderators and other gatewaying applications.
+ NOTE: The choice between UTF-8 and [RFC 2047] when posting
+ depends on various factors. Some reading agents do not recogize
+ [RFC 2047], and some are incapable of decoding UTF-8 (though
+ there in an increasing tendency for modern reading agents to
+ understand, or to be configurable to understand, both). Since
+ headers encoded in UTF-8 are currently prohibited in Email,
+ special consideration needs to be given to articles that are
+ both posted and mailed (6.9) or which are mailed to moderators
+ (see 8.2.2). Posters and implementors of posting agents need to
+ take account of all these factors when deciding which method to
+ use.
+
4.4.2. Character Sets within Article Bodies
***************
*** 1406,1410 ****
! NOTE: Observe that reading agents are not forbidden to "guess",
! or to interpret as UTF-8 regardless, which would be the simplest
! course for them to take.
--- 1437,1443 ----
! NOTE: Observe that reading agents are not forbidden to "guess"
! when confronted with unannounced non-ASCII characters, and in
! particular it would be reasonable at least to test whether they
! were in the form of valid UTF-8 (see also the suggestion for
! such a test in 4.4.1).
***************
*** 1564,1569 ****
! The From-header contains the electronic address(es), and possibly the
! full name, of the article's poster(s). The content syntax makes use
! of syntax defined in [RFC 2822], subject to the following revised
! definition of local-part.
--- 1599,1604 ----
! The From-header contains the email address(es), possibly including
! the full name(s), of the article's poster(s). The content syntax
! makes use of syntax defined in [RFC 2822], subject to the following
! revised definition of local-part.
***************
*** 1599,1602 ****
a valid address can subsequently be extracted from such an
! address falls outside the scope of this standard (though it
! would be pointless to use a disguise so easily penetrable).
--- 1634,1638 ----
a valid address can subsequently be extracted from such an
! address falls outside the scope of this standard (obviously,
! posters wishing to disguise their address need to do more than
! just add ".invalid" to it).
***************
*** 1604,1607 ****
to detect that the address belongs to the poster may choose to
! insert a Sender-header (6.2) or some entry in an Injector-Info-
! header (6.19) which discloses some valid address for the poster.
--- 1640,1644 ----
to detect that the address belongs to the poster may choose to
! insert a Sender-header (but see 8.2.2) or some entry in an
! Injector-Info-header (6.19) which discloses some valid address
! for the poster.
***************
*** 1746,1748 ****
--- 1783,1789 ----
Subject: Re: Godwin's law (was: Film at 11)
+ Subject: Re: Godwin's law
5.5. Newsgroups
***************
*** 1807,1811 ****
NOTE: As a result of of this restriction, a name has only one
! valid form. Implementations can assume that a straight
! comparison of characters or octets is sufficient to compare two
! newsgroup-names.
--- 1847,1851 ----
NOTE: As a result of of this restriction, a name has only one
! valid form. Implementations can assume that a straight (case
! sensitive) comparison of characters or octets is sufficient to
! compare two newsgroup-names.
***************
*** 1990,1998 ****
to the poster). Moreover, if a newsgroup-name contains any non-ASCII
! character, it MAY be encoded using the mechanism defined in [RFC
! 2047] when sent by email (for which purpose the newsgroup-name SHOULD
! be treated as an encoded-word) but, if it is subsequently returned to
! the Netnews environment, it MUST then be re-encoded into UTF-8. See
! also the further discussion in section 8.8.1.
! 5.5.1. Forbidden newsgroup names
--- 2030,2035 ----
to the poster). Moreover, if a newsgroup-name contains any non-ASCII
! character, it may need to be encoded using the mechanism defined in
! section 5.5.2. See also the further discussion in section 8.8.1.
! 5.5.1. Forbidden newsgroup-names
***************
*** 2024,2025 ****
--- 2059,2102 ----
+ 5.5.2. Encoded newsgroup-names
+
+ Where it is required to transport an article across some medium that
+ cannot reliably convey the full 8 bits of each octet, such as when
+ gatewaying it into Email (8.8.1), or when emailing it to a moderator
+ or constructing the submission address of the moderator (8.2.2), it
+ may be necessary to encode any newsgroup-name within a Newsgroups- or
+ Followup-To-header that contains any non-ASCII character. For that
+ purpose, the following algorithm is provided:
+
+ 1. Initially, the newsgroup-name is in the form of a sequence of
+ octets representing that name in the UTF-8 character set.
+
+ 2. Each octet in the name in the range 0x80-ff is replaced by a "%"
+ character, followed by two characters representing that octet in
+ hexadecimal, in which the hexadecimal digits "a" through "f" MUST
+ be in lowercase.
+
+
+ 3. Each octet in the name in the range 0x00-7f remains unaltered (and
+ thus MUST NOT be replaced by its hexadecimal equivalent).
+
+ NOTE: Observe that this algorithm provides a unique encoding for
+ each newsgroup-name. It will also be observed that it is
+ compatible with (but more retrictive than) that provided in [RFC
+ 2396] for use within Uniform Resource Identifiers.
+
+ This standard provides no authority for the use of this algorithm
+ other than in the context of Newsgroups-headers being conveyed by
+ email. In particular, it MUST NOT be used within any article conveyed
+ by the Netnews protocols and thus, if an email using it is
+ subsequently returned to the Netnews environment, it MUST be decoded
+ back into UTF-8.
+
+ NOTE: Although the encoding defined by [RFC 2047] is available
+ for use with other headers containing non-ASCII characters, the
+ Newsgroups-header, being a structured header, is not one of the
+ contexts permitted for its use (and moreover it would not
+ produce a unique encoding nor cope well with newsgroup-names of
+ excessive length). Therefore it SHOULD NOT be used within the
+ Newsgroups-header.
+
5.6. Path
***************
*** 2322,2329 ****
! The Sender-header specifies the mailbox of the entity which caused
! this article to be posted (and hence injected), if that entity is
! different from that given in the From-header or if more than one
! address appears in the From-header. This header SHOULD NOT appear in
! an article unless the sender is different from the poster. This
! header is appropriate for use by automatic article posters. The
content syntax makes use of syntax defined in [RFC 2822].
--- 2397,2404 ----
! The Sender-header specifies the mailbox of the person or entity which
! caused this article to be posted (and hence injected), if that person
! or entity is different from that given in the From-header or if more
! than one mailbox appears in the From-header. This header SHOULD NOT
! appear in an article unless the sender is different from the poster.
! This header is appropriate for use by automatic article posters. The
content syntax makes use of syntax defined in [RFC 2822].
***************
*** 2557,2561 ****
section 5.5. All other headers defined in this standard (excluding
! variant headers, but including specifically the Message-ID-header)
! MUST be identical in both the posted and mailed versions of the
! article, and so MUST the body.
--- 2632,2639 ----
section 5.5. All other headers defined in this standard (excluding
! variant headers) MUST be identical in both the posted and mailed
! versions of the article, except that headers containing UTF8-xtra-
! chars in the posted version MAY be encoded according to [RFC 2047] or
! [RFC 2231] in the emailed version. In particular, the Message-ID-
! headers MUST be identical. The bodies MUST be identical in both,
! apart from a possible change of Content-Transfer-Encoding.
***************
*** 2709,2713 ****
! The Approved-header indicates the mailing addresses (and possibly the
! full names) of the persons or entities approving the article for
! posting.
--- 2785,2789 ----
! The Approved-header indicates the mailing addresses (possibly
! including the full names) of the persons or entities approving the
! article for posting.
***************
*** 3242,3247 ****
sent as an attachment (i.e. as a part of a multipart) rather
! than as the top-level body of the email message. Moreover, it is
! anticipated that future extensions to the Email standards will
! permit headers containing UTF8-xtra-chars to be carried without
! further ado over conforming transports.
--- 3322,3324 ----
sent as an attachment (i.e. as a part of a multipart) rather
! than as the top-level body of the email message.
***************
*** 3393,3396 ****
the recipient should then inject them into Netnews. This Application
! type SHOULD be used when mailing articles to moderators and to
! email-to-news gateways (see 8.2.2).
--- 3475,3479 ----
the recipient should then inject them into Netnews. This Application
! type provides one of the methods for mailing articles to moderators
! (see 8.2.2) and it is also the preferred method when sending to an
! email-to-news gateway (see 8.8.1).
***************
*** 3706,3708 ****
other newsgroup-names. If the proto-article includes a Message-ID-
! header, the message indentifier in it MUST be different from that of
any existing article and from that of the control message as a whole.
--- 3788,3790 ----
other newsgroup-names. If the proto-article includes a Message-ID-
! header, the message identifier in it MUST be different from that of
any existing article and from that of the control message as a whole.
***************
*** 4240,4249 ****
mandatory headers for a proto-article (5 and 8.2.1) present, or
! which contains any header that does not have legal contents, and
! it SHOULD reject any article which contains any header deprecated
! for Netnews (4.2.1).
! 5. If the article is rejected, or is otherwise incorrectly formatted
! or unacceptable due to site policy, the posting agent SHOULD be
! informed (such as via an NNTP 44x response code) that posting has
! failed and the article MUST NOT then be processed further.
--- 4319,4333 ----
mandatory headers for a proto-article (5 and 8.2.1) present, or
! which contains any header that does not have legal contents. In
! particular, it MUST reject any article whose Newsgroups-header or
! Followup-To-header contains an encoded newsgroup-name (5.5.2);
! alternatively, it MAY decode those newsgroup-names and continue
! (this being a useful service for moderators using that injecting
! agent, see 8.7). It SHOULD reject any article which contains any
! header deprecated for Netnews (4.2.1).
! 5. If the article is rejected (for reasons given above, or for other
! formatting errors or matters of site policy) the posting agent
! SHOULD be informed (such as via an NNTP 44x response code) that
! posting has failed and the article MUST NOT then be processed
! further.
***************
*** 4279,4284 ****
!
! 11.If the Newsgroups line contains one or more moderated groups and
! the article does NOT contain an Approved-header, then the
injecting agent MUST forward it to the moderator of the first
--- 4363,4370 ----
+ 11.If the Newsgroups line contains no moderated groups, or if it
+ contains an Approved-header, the injecting agent forwards the
+ article to one or more relaying or serving agents.
! 12.Otherwise, when the Newsgroups line contains one or more moderated
! groups and the article does NOT contain an Approved-header, the
injecting agent MUST forward it to the moderator of the first
***************
*** 4285,4312 ****
(leftmost) moderated group listed in the Newsgroups line via
! email. The complete article SHOULD be encapsulated (headers and
! all) within the email, preferably using the Content-Type
! "application/news-transmission" (6.21.6.1).
! NOTE: This standard does not prescribe how the email address of
! the moderator is to be determined, that being a matter of policy
! to be arranged by the agency responsible for the oversight of
! each hierarchy. Nevertheless, there do exist various agents
! worldwide which provide the service of forwarding to moderators,
! and the address to use with them is obtained by replacing each
! '.' in the newsgroups-name with a '-'. For example, articles
! intended for "news.announce.important" would be emailed to
! "new-announce-important@forwardingagent.example".
! In the event that the newsgroup-name contains any UTF8-xtra-
! char, this will result in an addr-spec whose local-part is not
! consistent with the present email standards ([RFC 2822]). It is
! anticipated that extensions to those standards currently under
! consideration will in due course provide means for encoding such
! local-parts but, in the meantime, agencies responsible for
! creating moderated newsgroups with such names will need to make
! special arrangements.
! 12.Otherwise, the injecting agent forwards the article to one or more
! relaying or serving agents.
8.3. Duties of a Relaying Agent
--- 4371,4416 ----
(leftmost) moderated group listed in the Newsgroups line via
! email. There are two possibilities for doing this:
! (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.
+ 13.This standard does not prescribe how the email address of the
+ moderator is to be determined, that being a matter of policy to be
+ arranged by the agency responsible for the oversight of each
+ hierarchy. Nevertheless, there do exist various agents worldwide
+ which provide the service of forwarding to moderators, and the
+ address to use with them is obtained as follows:
+
+ (a) Each '.' in the newsgroups-name is replaced with a '-'.
+
+ (b) If the newsgroups-name contains any UTF8-xtra-char, it is
+ encoded as described in section 5.5.2.
+
+ (c) The result of these operations is used as the local-part of
+ the mailbox of the agent. For example, articles intended for
+ "news.announce.important" would be emailed to "new-announce-
+ important@forwardingagent.example".
+
8.3. Duties of a Relaying Agent
***************
*** 4505,4507 ****
5. Otherwise, he causes the article to be injected, having first
! observed all the duties of a posting agent (8.5).
--- 4605,4609 ----
5. Otherwise, he causes the article to be injected, having first
! decoded any encoded newgroup-name (5.5.2), unless his injecting
! agent offers that service (8.2.2), and having observed all the
! duties of a posting agent (8.5).
***************
*** 4513,4529 ****
! It should be the case that articles will be received by the moderator
! encapsulated as an object of Content-Type application/news-
! transmission (8.2.2), or possibly encapsulated but without an
! explicit Content-Type-header. In such a case, the complete article is
! immediately available for processing by the moderator.
- However, prior to the introduction of this standard, it was more
- common for injecting agents to transform proto-articles into email
- messages, mixing the Netnews headers with the Email headers.
- Moderators SHOULD therefore be prepared to accept submission in this
- format, although they need then to be aware of the Duties of an
- Incoming Gateway (8.8.2) (and, in particular, they SHOULD adopt the
- Message-ID- and Date-headers of the email message, though they SHOULD
- NOT add any Sender-header).
-
8.8. Duties of a Gateway
--- 4615,4626 ----
! 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.
8.8. Duties of a Gateway
***************
*** 4598,4605 ****
Where the format of the news article is incompatible with that of the
! target medium, it may be necessary to apply transformations. In
! particular, the presence of UTF8-xtra-chars in headers may be a
! source of such incompatibility when gatewaying into Email. On the
! other hand, some email systems (especially those supporting the
! 8BITMIME extensions [RFC 2821]) may well transport such material
! correctly, and some user agents may even display it.
--- 4694,4696 ----
Where the format of the news article is incompatible with that of the
! target medium, it may be necessary to apply transformations.
***************
*** 4615,4631 ****
! o Encapsulating the whole article as a message/rfc822 (6.21.2.2) may
! make it less likely to be mutilated during transport, especially
! where 8BITMIME is supported. Alternatively, encapsulating as an
! application/news-transmission (6.21.6.1) will guarantee correct
! transmission and is the method of choice where the intent is to
! gateway it back into Netnews later on.
! o Encoding words containing UTF8-xtra-chars according to [RFC 2047],
! where permitted by that standard (i.e. within phrases and
! unstructured headers), and preferably using the charset utf-8,
! should ensure their correct display upon arrival. Indeed, many
! user agents will display this encoding correctly in contexts not
! allowed by [RFC 2047].
! o In particular, treating a newsgroup-name as an encoded word
! according to [RFC 2047] is recommended (see also 5.5). Even if it
! is not decoded at the far end, it is preferable to display the
encoded form than to display nothing at all. Note, however, that
--- 4706,4750 ----
! o Transporting headers containing non-ASCII characters without first
! encoding them is contrary to the current Email standards [RFC
! 2821] and [RFC 2822]. This applies both to the top-level headers
! of the email, and also to headers contained within any embedded
! message or multipart Content-Types (and so recursively). However,
! it is well known that most mail transport agents will in fact
! convey these characters intact, especially for non-top-level
! headers in the case of transports which support the 8BITMIME
! extension, and it is to be expected that the prevalence of this
! ability will increase in the future (and may even be compliant
! with future versions of the Email standards). Moreover, many mail
! user agents will also display such characters correctly, or at
! least adequately. Therefore, some implementors of gateways may
! consider it an acceptable risk not to transform these headers in
! any way, especially in the case of the lower-level ones.
!
! NOTE: It is not the purpose of this standard either to condemn
! or to condone behaviours which may be non-compliant with other
! standards. That is a matter for those implementors.
!
! o Where an implementor considers the risk too high for the top-level
! headers, encapsulating the whole article as a message/rfc822
! (6.21.2.2) may make it less likely to be mutilated during
! transport, especially where 8BITMIME is supported. Alternatively,
! encapsulating as an application/news-transmission (6.21.6.1) will
! guarantee correct transmission in all cases and is the method of
! choice where the intent is to gateway it back into Netnews later
! on.
! o To ensure full compliance with the Email standards it is necessary
! to encode words containing UTF8-xtra-chars according to [RFC 2047]
! (but only where permitted by that standard, i.e. within phrases
! and unstructured headers, although many user agents will display
! this encoding correctly in other contexts also). Likewise, within
! parameters the proper encoding is that defined in [RFC 2231]. In
! both cases, it is preferable to encode using the charset UTF-8,
! although it might be wise first to confirm that that is indeed the
! charset which had been used (see 4.4.1).
! o In the case of newsgroup-names, as found in Newsgroups-headers,
! Followup-To-headers and some Control-headers, [RFC 2047] is not
! applicable (even though some mail reading agents might
! nevertheless display it correctly). Therefore, it is necessary to
! use the encoding described in section 5.5.2. Even if it is not
! decoded at the far end, it is preferable to display such an
encoded form than to display nothing at all. Note, however, that
***************
*** 4633,4637 ****
form before reinjection into any Netnews system.
- o Parameters whose values contain UTF8-xtra-chars may use the
- encoding defined in [RFC 2231], again preferably using the charset
- utf-8.
--- 4752,4753 ----
***************
*** 4755,4757 ****
forms containing the mailbox of the administrator of the gateway.
! Problems with the gateway may be reported to this address. The
display-name portion of this mailbox SHOULD indicate that the entity
--- 4872,4874 ----
forms containing the mailbox of the administrator of the gateway.
! Problems with the gateway may be reported to this mailbox. The
display-name portion of this mailbox SHOULD indicate that the entity
***************
*** 5104,5105 ****
--- 5221,5226 ----
+ [RFC 2396] T. Berners-Lee, R. Fielding, U.C. Irvine, and L. Masinter,
+ "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396,
+ August 1998.
+
[RFC 2440] J. Callas, L. Donnerhacke, H. Finney, and R. Thayer,
***************
*** 5163,5190 ****
Ralph Babel David C. Lawrence
! Stan Barber Simon Lyall
! Dave Barr Todd Michel McComb
! Ian Bell Denis McKeon
! G. James Berigan Seymour J. Metz
! Terje Bless John Moreno
! Seth Breidbart Chris Newman
! Buddha Buck Dirk Nimmich
! Forrest J. Cavalier III Paul Overell
! Evan Champion Jacob Palme
! Maurizio Codogno Brian Palmer
! Don Croyle Pete Resnick
! Matt Curtin Jon Ribbens
! Bill Davidsen Dan Ritter
! Ian Davis Thomas Roessler
! Jean-Marc Desperrier Doug Royer
! Martin J. Duerst Frederic Senis
! Claus Andre Faerber Erland Sommarskog
! Clive D.W. Feather Henry Spencer
! David Formosa John Stanley
! Marty Fouts Brad Templeton
! Benjamin Franz Florian Weimer
! Andrew Gierth Curt Welch
! Jonathan Grobe Curtis Whalen
! Thomas Gschwind Leonid Yegoshin
! Kai Henningsen Jamie Zawinski
! Lars Magne Ingebrigtsen
--- 5285,5312 ----
Ralph Babel David C. Lawrence
! Stan Barber Bruce Lilly
! Dave Barr Simon Lyall
! Ian Bell Todd Michel McComb
! G. James Berigan Denis McKeon
! Terje Bless Seymour J. Metz
! Seth Breidbart John Moreno
! Buddha Buck Chris Newman
! Forrest J. Cavalier III Dirk Nimmich
! Evan Champion Paul Overell
! Maurizio CodognoJacob Palme
! Don Croyle Brian Palmer
! Matt Curtin Pete Resnick
! Bill Davidsen Jon Ribbens
! Ian Davis Dan Ritter
! Jean-Marc Desperrier Thomas Roessler
! Martin J. Duerst Doug Royer
! Claus Andre Faerber Frederic Senis
! Clive D.W. Feather Erland Sommarskog
! David Formosa Henry Spencer
! Marty Fouts John Stanley
! Benjamin Franz Brad Templeton
! Andrew Gierth Florian Weimer
! Jonathan Grobe Curt Welch
! Thomas Gschwind Curtis Whalen
! Kai Henningsen Leonid Yegoshin
! Lars Magne Ingebrigtsen Jamie Zawinski
***************
*** 5222,5224 ****
This draft expires six months after the date of publication (see Page
! 1) (i.e. in Dec 2002).
--- 5341,5343 ----
This draft expires six months after the date of publication (see Page
! 1) (i.e. in Jan 2003).
***************
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