1 Aug 2002 15:51
Final Last Last Last Call
Charles Lindsey <chl <at> clw.cs.man.ac.uk>
2002-08-01 13:51:19 GMT
2002-08-01 13:51:19 GMT
The recent discussion on the moderators' list has revealed some
opposition from Jay (who will never be convinced whatever we do)
together with much support for encapsulation (as an ultimate Good Thing)
from members of this list.
I think this shows that our general approach now has consensus on this
list. There are differing views on which approach (encapsulation vs
encoding) will or should succeed in the long term, but our draft is more
or less neutral on that issue.
I have therefore had a final check through the document and prepared
what I hope will be the final draft. It is my intention to put this
up as an internet draft next Tuesday, and at the same time to ask our
chairman to submit it for IETF Last Call.
IF ANY MEMBER OF THIS LIST HAS OBJECTIONS TO THIS PROCEDURE, LET HIM
SPEAK UP NOW.
The full diffs follow.The changes are mostly mind-bogglingly boring.
Fixing of typos and incsonsistencies in terminology.
The only matters of substance are two further consequentials of our
recent changes. One is a reference to the new 5.2.2 encoding in
section 6.9 (Posted-And-Mailed) and the other is in section 6.21.2.2
(message/rfc822). That used to describe various problems in sending a
message/rfc822 over a 7bit channel. Since we have now written extensive
new wording in section 8.8.1 (Duties of an Outgoing Gateway) on this
topic, I have replaced that wording with a pointer to 8.8.1, thus saving
quite a bit of verbiage. I have also taken the opportunity to include a
reference to the obsolete message/news in section 6.21.6.2 (since that
obsoleting was the main reason for discussing message/rfc822 in the
first place).
*** draft-ietf-usefor-article-07.02.unpaged Wed Jul 24 17:10:18 2002
--- draft-ietf-usefor-article-08.unpaged Thu Aug 1 14:15:51 2002
***************
*** 3,5 ****
Usenet Format Working Group University of Manchester
! July 2002
--- 3,5 ----
Usenet Format Working Group University of Manchester
! August 2002
***************
*** 6,8 ****
News Article Format
! <draft-ietf-usefor-article-07.02.txt>
--- 6,8 ----
News Article Format
! <draft-ietf-usefor-article-08.txt>
***************
*** 675,677 ****
contradistinction to [RFC 2822], the Netnews protocols are
! sensitive to case in some instances (as in newsgroup names, some
header parameters, etc.). Care has been taken to indicate this
--- 675,677 ----
contradistinction to [RFC 2822], the Netnews protocols are
! sensitive to case in some instances (as in newsgroup-names, some
header parameters, etc.). Care has been taken to indicate this
***************
*** 805,807 ****
existing usage that complies with the previous standards, since
! US-ASCII is a strict subset of UTF-8. Insofar as newsgroup names
containing non-ASCII characters can now be expected to arise,
--- 805,807 ----
existing usage that complies with the previous standards, since
! US-ASCII is a strict subset of UTF-8. Insofar as newsgroup-names
containing non-ASCII characters can now be expected to arise,
***************
*** 911,913 ****
Despite the restrictions on header-name syntax imposed by the
! grammar, relayers and reading agents SHOULD tolerate header-names
containing any US-ASCII printable character other than colon (":",
--- 911,913 ----
Despite the restrictions on header-name syntax imposed by the
! grammar, relaying and reading agents SHOULD tolerate header-names
containing any US-ASCII printable character other than colon (":",
***************
*** 1352,1355 ****
together with the more elaborate characters used in Asian
! countries. See the following section for the appropriate
! treatment of Unicode characters by reading agents.
[The sentence mentioning [RFC 2279] could be simplified if [RFC 2279bis]
--- 1352,1355 ----
together with the more elaborate characters used in Asian
! countries. See the NOTEs in the following section for the
! appropriate treatment of Unicode characters by reading agents.
[The sentence mentioning [RFC 2279] could be simplified if [RFC 2279bis]
***************
*** 1824,1828 ****
combiner-ASCII = DIGIT / ALPHA / "+" / "-" / "_"
! combiner-extended = <any character with a Unicode code value of
! 0080 or greater but excluding any character
! in Unicode categories Cc, Cf, Cs, M* and Z*>
combiner-mark = <any character with a Unicode code value of
--- 1824,1829 ----
combiner-ASCII = DIGIT / ALPHA / "+" / "-" / "_"
! combiner-extended = <any character with a Unicode code value
! of 0080 or greater but excluding any
! character in Unicode categories
! Cc, Cf, Cs, M* and Z*>
combiner-mark = <any character with a Unicode code value of
***************
*** 1866,1868 ****
NOTE: An implementation is not required to apply NFKC, or any
! other normalization, to newsgroup names. Only agencies that
create new groups need to be careful to obey this restriction
--- 1867,1869 ----
NOTE: An implementation is not required to apply NFKC, or any
! other normalization, to newsgroup-names. Only agencies that
create new groups need to be careful to obey this restriction
***************
*** 1876,1878 ****
Components beginning with underline ("_") are reserved for use by
! future versions of this standard and MUST NOT occur in newsgroup
names (whether in Newsgroups-headers or in newgroup control messages
--- 1877,1879 ----
Components beginning with underline ("_") are reserved for use by
! future versions of this standard and MUST NOT occur in newsgroup-
names (whether in Newsgroups-headers or in newgroup control messages
***************
*** 1881,1883 ****
Components beginning with "+" or "-" are reserved for use by
! implementations and MUST NOT occur in newsgroup names (whether in
Newsgroups-headers or in newgroup control messages). Implementors may
--- 1882,1884 ----
Components beginning with "+" or "-" are reserved for use by
! implementations and MUST NOT occur in newsgroup-names (whether in
Newsgroups-headers or in newgroup control messages). Implementors may
***************
*** 1896,1898 ****
no such specific policy, the following restrictions SHOULD be applied
! to newsgroup names.
--- 1897,1899 ----
no such specific policy, the following restrictions SHOULD be applied
! to newsgroup-names.
***************
*** 1939,1941 ****
! [4] Traditionally newsgroup names have only used letters, digits,
and the three special characters "+", "-" and "_". These
--- 1940,1942 ----
! [4] Traditionally newsgroup-names have only used letters, digits,
and the three special characters "+", "-" and "_". These
***************
*** 1962,1964 ****
octets) nor of a newsgroup-name, it should be noted that these
! names are also used in the newsgroups line (7.2.1.2) where an
overall policy limit applies and, moreover, excessively long names
--- 1963,1965 ----
octets) nor of a newsgroup-name, it should be noted that these
! names are also used in the newsgroups-line (7.2.1.2) where an
overall policy limit applies and, moreover, excessively long names
***************
*** 2055,2057 ****
A newsgroup-name SHOULD NOT appear more than once in the Newsgroups-
! header. The order of newsgroup names in the Newsgroups-header is not
significant, except for determining which moderator to send the
--- 2056,2058 ----
A newsgroup-name SHOULD NOT appear more than once in the Newsgroups-
! header. The order of newsgroup-names in the Newsgroups-header is not
significant, except for determining which moderator to send the
***************
*** 2534,2536 ****
Followup-To-header, the default newsgroup(s) for a followup are those
! in the Newsgroups header, and for this reason the Followup-To-header
SHOULD NOT be included if it just duplicates the Newsgroups-header.
--- 2534,2536 ----
Followup-To-header, the default newsgroup(s) for a followup are those
! in the Newsgroups-header, and for this reason the Followup-To-header
SHOULD NOT be included if it just duplicates the Newsgroups-header.
***************
*** 2635,2639 ****
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.
--- 2635,2640 ----
chars in the posted version MAY be encoded according to [RFC 2047] or
! [RFC 2231], or (in the case of a Newsgroups-header) to section 5.5.2,
! 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.
***************
*** 2855,2857 ****
The Xref-header is a variant header (4.2.5.3) which indicates where
! an article was filed by the last server to process it.
--- 2861,2863 ----
The Xref-header is a variant header (4.2.5.3) which indicates where
! an article was filed by the last serving agent to process it.
***************
*** 3296,3325 ****
have already been posted to Netnews and which are for the information
! of the recipient, and do not constitute a request to repost them.
! In the case where the encapsulated article has Content-Transfer-
! Encoding "8bit", it will be necessary to change that encoding if it
! is to be forwarded over some email transport that only supports
! "7bit". However, this should not be necessary for any email transport
! that supports the 8BITMIME feature [RFC 2821]. Moreover, where the
! headers of the encapsulated article contain any UTF8-xtra-chars
! (2.4.2), it may not be possible to transport them over email
! transports even where 8BITMIME is supported. In such cases, it will
! be necessary to encode those headers as provided in [RFC 2047]
! (notwithstanding that such usage is deprecated for news headers by
! this standard, and actually forbidden in the case of the Newsgroups-
! header).
- In the event that the encapsulated article has to be encoded for
- either of these reasons, it may be necessary to reverse that encoding
- if certain forms of digital signatures have been employed, or if the
- article is to be reintroduced into some Netnews system (however, in
- the latter case, the Content-Type "application/news-transmission"
- should have been used instead).
-
- NOTE: It is likely, though not guaranteed, that headers
- containing UTF8-xtra-chars will pass safely through email
- transports supporting 8BITMIME if the "message/rfc822" object is
- sent as an attachment (i.e. as a part of a multipart) rather
- than as the top-level body of the email message.
-
6.21.2.3. Message/external-body
--- 3296,3312 ----
have already been posted to Netnews and which are for the information
! of the recipient, and do not constitute a request to repost them
! (refer to 6.21.6.2 for the now obsolete "message/news" formerly
! intended for this purpose).
! In the case where such an encapsulated news article has Content-
! Transfer-Encoding "8bit" or where its headers contain any UTF8-xtra-
! chars (2.4.2), it might not be possible to transport it my email
! without some prior transformations, although there should be few
! problems if the email transport supports 8BITMIME [RFC 2821]. The
! problems that arise are similar to those encountered by an outgoing
! gateway, and therefore the advice on transformations given in section
! 8.8.1 should be followed. It may be necessary to reverse such
! transformations at the far end if certain forms of digital signatures
! have been employed in the article.
6.21.2.3. Message/external-body
***************
*** 3678,3680 ****
2. Other parts containing useful information about the background of
! the newsgroup message (typically of type "text/plain").
--- 3662,3664 ----
2. Other parts containing useful information about the background of
! the newgroup message (typically of type "text/plain").
***************
*** 3767,3771 ****
use of UTF-8 when such a description is transmitted by the LIST
! NEWSGROUPS command, it would also be convenient for servers that
! keep a "newsgroups" file to store them in that form, so as to
! avoid unnecessary conversions.
[If, at the time of publication of this standard, [NNTP] is still [RFC
--- 3749,3753 ----
use of UTF-8 when such a description is transmitted by the LIST
! NEWSGROUPS command, it would also be convenient for serving
! agents that keep a "newsgroups" file to store them in that form,
! so as to avoid unnecessary conversions.
[If, at the time of publication of this standard, [NNTP] is still [RFC
***************
*** 3796,3803 ****
processes the control message AFTER the newsgroup in question has
! been created or modified. It MUST NOT be injected if the newsgroup is
! not, in fact, created (for whatever reason). It MUST NOT be submitted
! to any relaying agent for transmission beyond the server(s) upon
! which the newsgroup creation has just been effected (in other words,
! it is to be treated as having a "Distribution: local" header,
! whether such a header is actually present or not).
--- 3782,3789 ----
processes the control message AFTER the newsgroup in question has
! been created or modified. It MUST NOT be injected if the newsgroup
! is not, in fact, created (for whatever reason). It MUST NOT be
! submitted to any relaying agent for transmission beyond the serving
! agent(s) upon which the newsgroup creation has just been effected (in
! other words, it is to be treated as having a "Distribution: local"
! header, whether such a header is actually present or not).
***************
*** 4363,4365 ****
! 11.If the Newsgroups line contains no moderated groups, or if it
contains an Approved-header, the injecting agent forwards the
--- 4354,4356 ----
! 11.If the Newsgroups-header contains no moderated groups, or if it
contains an Approved-header, the injecting agent forwards the
***************
*** 4367,4373 ****
! 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
! (leftmost) moderated group listed in the Newsgroups line via
! email. There are two possibilities for doing this:
--- 4358,4364 ----
! 12.Otherwise, when the Newsgroups-header 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 (leftmost) moderated group listed in the Newsgroups-
! header via email. There are two possibilities for doing this:
***************
*** 4405,4409 ****
- (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.
--- 4396,4402 ----
!
! (a) Each '.' in the newsgroup-name is replaced with a '-'.
!
! (b) If the newsgroup-name contains any UTF8-xtra-char, it is
encoded as described in section 5.5.2.
***************
*** 4412,4415 ****
the mailbox of the agent. For example, articles intended for
! "news.announce.important" would be emailed to "new-announce-
! important <at> forwardingagent.example".
--- 4405,4408 ----
the mailbox of the agent. For example, articles intended for
! "news.announce.important" would be emailed to "news-
! announce-important <at> forwardingagent.example".
***************
*** 4605,4607 ****
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
--- 4599,4601 ----
5. Otherwise, he causes the article to be injected, having first
! decoded any encoded newsgroup-name (5.5.2), unless his injecting
agent offers that service (8.2.2), and having observed all the
***************
*** 5213,5215 ****
[RFC 2279bis] F. Yergeau, "UTF-8, a transformation format of ISO
! 10646", RFC 2279, April 2002.
--- 5210,5212 ----
[RFC 2279bis] F. Yergeau, "UTF-8, a transformation format of ISO
! 10646", draft-yergeau-rfc2279bis-00.txt, April 2002.
***************
*** 5294,5296 ****
Evan Champion Paul Overell
! Maurizio CodognoJacob Palme
Don Croyle Brian Palmer
--- 5291,5293 ----
Evan Champion Paul Overell
! Maurizio Codogno Jacob Palme
Don Croyle Brian Palmer
***************
*** 5341,5343 ****
This draft expires six months after the date of publication (see Page
! 1) (i.e. in Jan 2003).
--- 5339,5341 ----
This draft expires six months after the date of publication (see Page
! 1) (i.e. in Feb 2003).
***************
*** 5403,5406 ****
were approximately as now. The Received-header contained the date
! when the latest relayer to process the article first saw it. All
! dates were in the above format, with all fields fixed width,
resembling an Internet date but not quite the same.
--- 5391,5394 ----
were approximately as now. The Received-header contained the date
! when the latest relaying agent to process the article first saw it.
! All dates were in the above format, with all fields fixed width,
resembling an Internet date but not quite the same.
***************
*** 5419,5425 ****
! Relay-Version contained version information about the relayer that
! last processed the article. Posting-Version contained version
information about the posting agent that posted the article. Date-
! Received contained the date when the last relayer to process the
! article first saw it (in a slightly nonstandard format).
--- 5407,5413 ----
! Relay-Version contained version information about the relaying agent
! that last processed the article. Posting-Version contained version
information about the posting agent that posted the article. Date-
! Received contained the date when the last relaying agent to process
! the article first saw it (in a slightly nonstandard format).
***************
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 <at> 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
RSS Feed