[NNTP] STREAMING diffs (take 2)
Ken Murchison
ken at oceana.com
Fri Jun 10 08:18:04 PDT 2005
2 small editorial tweaks from Jeff and Clive. Do people feel this this
has addressed all important issues brought up in last call?
--- streaming-5.txt 2005-06-09 14:17:54.000000000 -0400
+++ streaming-6.txt 2005-06-10 11:15:19.000000000 -0400
@@ -6,13 +6,13 @@
NNTP Extensions Working Group J. Vinocur
Internet Draft Cornell University
-Updates: 2970 (if approved) K. Murchison
+Updates: 2980 (if approved) K. Murchison
Expires: December 2005 Oceana Matrix Ltd.
June 2005
NNTP Extension for Streaming Feeds
- draft-ietf-nntpext-streaming-05
+ draft-ietf-nntpext-streaming-06
Status of this memo
@@ -46,23 +46,31 @@
Abstract
This memo defines an extension to the Network News Transport
- Protocol [NNTP] to provide asynchronous (otherwise known as
+ Protocol (NNTP) to provide asynchronous (otherwise known as
"streaming") transfer of articles. This allows servers to transfer
articles to other servers with much greater efficiency.
- Section 1 of [NNTP-COMMON] summarizes some ad-hoc transport
- extensions currently used in the NNTP protocol. This document
- updates and formalizes the CHECK and TAKETHIS commands and
- deprecates the MODE STREAM command.
+ This document updates and formalizes the CHECK and TAKETHIS
+ commands specified in RFC 2980 and deprecates the MODE STREAM
+ command.
+
+Note to the RFC Editor
+
+ The normative reference to RFC 2234 may be replaced by
+ draft-crocker-abnf-rfc2234bis should it reach RFC status before
+ this one.
+
+ The normative reference to [NNTP] is a document which is expected
+ to be published simultaneously with this one and so can be replaced
+ by reference to the resulting RFC.
Table of Contents
- 0. Changes from Previous Version ............................ 2
1. Introduction ............................................. 3
1.1. Conventions Used in this Document ................... 3
2. The STREAMING Extension .................................. 3
- 2.1. Advertising the STREAMING Extension ................. 3
- 2.2. Streaming Article Transfer .......................... 4
+ 2.1. Streaming Article Transfer .......................... 3
+ 2.2. Advertising the STREAMING Extension ................. 4
2.3. MODE STREAM Command ................................. 5
2.3.1. Usage .......................................... 5
2.3.2. Description .................................... 5
@@ -76,44 +84,38 @@
2.5.2. Description .................................... 7
2.5.3. Examples ....................................... 8
3. Augmented BNF Syntax for the STREAMING Extension ......... 9
- 3.1. Commands ............................................ 9
+ 3.1. Commands ............................................ 10
3.2. Command Datastream .................................. 10
3.3. Responses ........................................... 10
3.4. Capability entries .................................. 10
- 4. Summary of Response Codes ................................ 10
+ 4. Summary of Response Codes ................................ 11
5. Security Considerations .................................. 11
6. IANA Considerations ...................................... 11
7. References ............................................... 12
7.1. Normative References ................................ 12
- 7.2. Informative References .............................. 12
+ 7.2. Informative References .............................. 13
8. Authors' Addresses ....................................... 13
9. Acknowledgments .......................................... 13
10. Intellectual Property Rights ............................ 13
11. Copyright ............................................... 14
-0. Changes from Previous Version
-
- Changed:
- o Updated to RFC 3978/3979 boilerplate.
- o Uses new ABNF tokens from [NNTP].
- o Uses new "multi-line data block" term from [NNTP].
- o POST has its own capability.
-
- Clarified:
- o Section 3: This document extends the ABNF in [NNTP], and the
- [NNTP] ABNF must be imported first before validating the
- STREAMING ABNF (based on recommendations of AD regarding
- IMAPEXT I-Ds).
-
1. Introduction
According to the NNTP specification [NNTP], a peer uses the IHAVE
command to query whether a server wants a particular article.
Because the IHAVE command cannot be pipelined, the need to stop and
wait for the remote end's response greatly restricts the throughput
- that can be achieved. The alternative method of peer-to-peer
- article transfer described in this document permits a more
- consistent use of network bandwidth.
+ that can be achieved.
+
+ The ad-hoc CHECK and TAKETHIS commands, originally documented in
+ [NNTP-COMMON], provide an alternative method of peer-to-peer
+ article transfer which permits a more effective use of network
+ bandwidth. Due to their proven usefulness and wide deployment,
+ they are formalized in this specification.
+
+ The ad-hoc MODE STREAM command, also documented in [NNTP-COMMON],
+ is deprecated by this specification, but due to its ubiquity is
+ documented here for backwards compatibility.
1.1. Conventions Used in this Document
@@ -139,7 +141,36 @@
This extension provides three new commands: MODE STREAM, CHECK, and
TAKETHIS. The capability label for this extension is STREAMING.
-2.1. Advertising the STREAMING Extension
+2.1. Streaming Article Transfer
+
+ The STREAMING extension provides the same functionality as the
+ IHAVE command ([NNTP] section 6.3.2) but splits the query and
+ transfer functionality into the CHECK and TAKETHIS commands
+ respectively. This allows the CHECK and TAKETHIS commands to be
+ pipelined ([NNTP] section 3.5) and provides for "streaming" article
+ transfer.
+
+ A streaming client will often pipeline many CHECK commands and use
+ the responses to construct a list of articles to be sent by a
+ pipelined sequence of TAKETHIS commands, thus increasing the
+ fraction of time spent transferring articles. The CHECK and
+ TAKETHIS commands utilize distinct response codes so that these
+ commands can be intermingled in a pipeline and the response to any
+ single command can be definitively identified by the client.
+
+ The client MAY send articles via TAKETHIS without first querying
+ the server with CHECK. The client SHOULD NOT send every article in
+ this fashion unless explicitly configured to do so by the site
+ administrator based on out-of-band information. However, the
+ client MAY use an adaptive strategy where it initially sends CHECK
+ commands for all articles, but switches to using TAKETHIS without
+ CHECK if most articles are being accepted (over 95% acceptance
+ might be a reasonable metric in some configurations). If the
+ client uses such a strategy, it SHOULD also switch back to using
+ CHECK on all articles if the acceptance rate ever falls much below
+ the threshold.
+
+2.2. Advertising the STREAMING Extension
A server supporting the streaming commands described in this
document will advertise the "STREAMING" capability label in
@@ -180,35 +211,6 @@
[S] HDR
[S] .
-2.2. Streaming Article Transfer
-
- The STREAMING extension provides the same functionality as the
- IHAVE command ([NNTP] section 6.3.2) but splits the query and
- transfer functionality into the CHECK and TAKETHIS commands
- respectively. This allows the CHECK and TAKETHIS commands to be
- pipelined (unlike IHAVE) and provides for "streaming" article
- transfer.
-
- A streaming client will often pipeline many CHECK commands and use
- the responses to construct a list of articles to be sent by a
- pipelined sequence of TAKETHIS commands, thus increasing the
- fraction of time spent transferring articles. The CHECK and
- TAKETHIS commands utilize distinct response codes so that these
- commands can be intermingled in a pipeline and the response to any
- single command can be definitively identified by the client.
-
- The client MAY send articles via TAKETHIS without first querying
- the server with CHECK. The client SHOULD NOT send every article in
- this fashion unless explicitly configured to do so by the site
- administrator based on out-of-band information. However, the
- client MAY use an adaptive strategy where it initially sends CHECK
- commands for all articles, but switches to using TAKETHIS without
- CHECK if most articles are being accepted (over 95% acceptance may
- be a reasonable metric in some configurations). If the client uses
- such a strategy, it SHOULD also switch back to using CHECK on all
- articles if the acceptance rate ever falls much below the
- threshold.
-
2.3. MODE STREAM Command
Historically this command was used by a client to discover if a
@@ -240,9 +242,11 @@
If a server supports this extension, it MUST return a 203 response
to the MODE STREAM command (or 501 if an argument is given). The
- MODE STREAM command MUST NOT affect the server state in any way. A
- server MUST NOT require that the MODE STREAM command be issued by
- the client before accepting the CHECK or TAKETHIS commands.
+ MODE STREAM command MUST NOT affect the server state in any way
+ (that is, it is not a mode change despite the name), therefore this
+ command MAY be pipelined. A server MUST NOT require that the MODE
+ STREAM command be issued by the client before accepting the CHECK
+ or TAKETHIS commands.
2.3.3. Examples
@@ -339,16 +343,16 @@
message-id to the server. The article is sent immediately
following the CRLF at the end of the TAKETHIS command line. The
client MUST send the entire article, including headers and body, to
- the server as a multi-line data block (see Section 3.1.1 of
- [NNTP]). Thus a single dot (".") on a line indicates the end of
- the text, and lines starting with a dot in the original text have
- that dot doubled during transmission. The server MUST return
- either a 239 response, indicating that the article was successfully
- transferred, or a 439 response, indicating that the article was
- rejected. If the server encounters a temporary error that prevents
- it from processing the article but does not want to reject the
- article, it MUST reply with a 400 response to the client and close
- the connection.
+ the server as a multi-line data block ([NNTP] section 3.1.1). Thus
+ a single dot (".") on a line indicates the end of the text, and
+ lines starting with a dot in the original text have that dot
+ doubled during transmission. The server MUST return either a 239
+ response, indicating that the article was successfully transferred,
+ or a 439 response, indicating that the article was rejected. If
+ the server encounters a temporary error that prevents it from
+ processing the article but does not want to reject the article, it
+ MUST reply with a 400 response to the client and close the
+ connection.
This function differs from the POST command in that it is intended
for use in transferring already-posted articles between hosts. It
@@ -602,9 +606,9 @@
[NNTP-COMMON], by Stan Barber.
Special acknowledgment also goes to Russ Allbery, Clive Feather,
- and others who commented privately on intermediate revisions of
- this document, as well as the members of the IETF NNTP Working
- Group for continual (yet sporadic) insight in discussion.
+ Andrew Gierth, and others who commented privately on intermediate
+ revisions of this document, as well as the members of the IETF NNTP
+ Working Group for continual (yet sporadic) insight in discussion.
10. Intellectual Property Rights
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp
More information about the ietf-nntp
mailing list