[ietf-nntp] RE: How to organize the base NNTP draft
Clive D.W. Feather
clive at demon.net
Tue Jun 8 08:09:21 PDT 2004
Russ Allbery said:
> Once those are both in WG last call, or maybe IETF last call, maybe the
> IESG can advance the base document (with the changes required from the
> other comments received so far)?
Apropos of this, I have just uploaded a pre-release version of a potential
draft 23 (it's called pre-release 3 for reasons that aren't important).
This contains changes based on either comments from IESG or that came up in
subsequent discussion.
The draft is available at:
<http://www.davros.org/nntp-texts/draft23.pre-3.txt>
<http://www.davros.org/nntp-texts/draft23.pre-3.html>
The total changes are:
* Renumbered and redated.
* "draft" changed to "document" in various places.
* In 1 para 3, after "US-ASCII" insert:
(note that US-ASCII is a subset of UTF-8).
* In 1 para 3, after:
eliminating the "<0>" placeholder used in RFC 977
insert:
in some responses.
* In 2 para 5, change:
< with those codes in US-ASCII
< (that is, %x00, %x09, %x0A, %x0D, and %x20 respectively),
< as do quoted characters (so "." and "<" refer to %x2E and %x3C).
---
> %x00, %x09, %x0A, %x0D, and %x20 respectively (that is, the octets
> with those codes in US-ASCII and thus UTF-8).
and add to the paragraph:
Quoted characters refer to the octets with those codes in US-ASCII
(so "." and "<" refer to %x2E and %x3C) and will always be printable
US-ASCII characters; similarly, "digit" refers to the octets %x30-39.
* In 2 para 6, add:
Examples may use commands (or other names) not defined in this
specification (such as an XENCRYPT command). These will be used to
illustrate some point and do not imply that any such command is
defined elsewhere or needs to exist in any particular implementation.
* In 3.1, after:
Note that texts using an encoding (such as UTF-16 or UTF-32) that may
contain the octets NUL, LF, or CR other than a CRLF pair cannot be
reliably conveyed in the above format
add:
(that is, they violate the MUST requirement above)
and change:
it is possible for octets above and below 128 to be mixed arbitrarily.
to:
it MAY include octets above and below 128 mixed arbitrarily.
* In 3.2, after:
for historical reasons, the 211 response code is an exception to this
add:
in that the response may be multi-line or not depending on the command
(GROUP or LISTGROUP) that generated it.
* Append to 3.4 para 4:
How the client will then process those headers, including identifying
the encoding used, is outside the scope of this document.
* In 5.1.1, the unnumbered comment becomes "[1]" and "[1]" becomes "[2]".
* In 5.3.2 LIST EXTENSIONS, add:
A server MUST NOT generate the generic response 401, 480, 483, or 502
(all of which indicate "not permitted") to this command.
and after "uppercase" add "(that is, %x41-5A)".
* In 5.4.2 QUIT, add:
The server MUST NOT generate any response code to the QUIT command
other than 205 or, if any arguments are provided, 501.
* In ARTICLE, HEAD, BODY, and STAT, change the meaning of 423 from either:
423 No articles in that range
423 No such article number in this group
to:
423 No article with that number
but leaving the OVER and HDR meanings unaltered. In appendix C change
Meaning: no articles in that range.
to:
Meaning: no article with that number or in that range.
* In 8.3.1.2 LISTGROUP, add:
As a side effect, it also selects the group in the same way as the
the GROUP command
and move "(see Section 6.1.1)" to here; also add "On success" to the
description of 211.
* A number of changes to the ABNF, as follows.
* Fixed errors noted in the review, and ran the validator over the code.
* Added a new section 9.2 (renumbering subsequent sections):
9.2 Command continuation
This syntax defines the further material sent by the client in the
case of multi-stage commands.
command-continuation = ihave-continuation /
post-continuation
ihave-continuation = encoded-article
post-continuation = encoded-article
encoded-article = content-lines termination
; after undoing the "byte-stuffing", this MUST match "article"
* Moved:
newsgroup-name
termination
content-text
wildmat
wildmat-pattern
wildmat-item
wildmat-exact
wildmat-wild
to 9.7 (general non-terminals).
* In (new) 9.3, changed:
multiline-response = simple-response *content-line termination
content-line = [content-text] CRLF
to:
multiline-response = simple-response content-lines termination
content-lines = *([content-text] CRLF)
(the latter in 9.7).
* In (new) 9.4, after:
This syntax defines the content of the various multi-line responses
added:
(more precisely, the part of the response in "content-lines")
* In (new) 9.4, changed the LIST EXTENSIONS response from:
list-extensions-response =
*(extension-label *(SPA extension-argument) CRLF)
to:
list-extensions-response =
*(extension-descriptor CRLF)
extension-descriptor = extension-generic-descriptor
extension-generic-descriptor =
extension-label *(SPA extension-argument)
* Added a new section 9.5 (renumbering subsequent sections):
9.5 LIST EXTENSIONS responses
This syntax defines the specific LIST EXTENSIONS responses for the
various extensions in this specification.
extension-descriptor /= hdr-extension /
listgroup-extension /
over-extension
hdr-extension = %x48.44.52 ; "HDR"
listgroup-extension = %x4C.49.53.54.47.52.4F.55.50 ; "LISTGROUP"
over-extension = %x4F.56.45.52 [SPA "MSGID"] ; "OVER"
* In (new) 9.7, changed:
; A- means based on ASCII, excluding controls and SP
to:
; A- means based on US-ASCII, excluding controls and SP
* In 12 Acknowledgements, added:
This document is the result of much effort by the NNTP Working Group,
chaired by Russ Allbery and Ned Freed. It could not have been produced
without them.
(should we be adding a list of names?) and merged some other items into a
bullet list.
* Formatting fix in Appendix C, code 211.
--
Clive D.W. Feather | Work: <clive at demon.net> | Tel: +44 20 8495 6138
Internet Expert | Home: <clive at davros.org> | Fax: +44 870 051 9937
Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc | |
More information about the ietf-nntp
mailing list