rfc-4644

Network News Transfer Protocol (NNTP) Extension for Streaming Feeds

J. Vinocur, K. Murchison
date2006-10 streamIETF areaapp wgnntpext statusPROPOSED STANDARD pages14 canonicalhttps://www.rfc-editor.org/rfc/rfc4644 doi10.17487/RFC4644 errataview
This memo defines an extension to the Network News Transfer 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. This document updates and formalizes the CHECK and TAKETHIS commands specified in RFC 2980 and deprecates the MODE STREAM command. [STANDARDS-TRACK]

updates

Extracted elements (25)

design-rationale §2.1

CHECK and TAKETHIS use distinct response codes (238/431/438 vs 239/439) so that these commands can be intermingled in a pipeline and the response to any single command can be definitively identified by the client.

design-rationale §1

The IHAVE command cannot be pipelined, so stopping to wait for each response greatly restricts throughput. CHECK and TAKETHIS split the query and transfer functionality to allow pipelining and achieve streaming article transfer.

design-rationale §2.3

The MODE STREAM command is deprecated in favor of CAPABILITIES discovery but is retained for backwards compatibility with legacy implementations documented in RFC 2980. It may be removed from a future version of this specification.

interoperability-note §2.5.2

Because some news server software may not immediately determine whether an article is suitable, a server MAY acknowledge successful transfer (239) but later silently discard the article. Clients cannot rely on 239 as a guarantee of propagation.

interoperability-note §1

This document updates RFC 2980, formalizing the ad-hoc CHECK and TAKETHIS commands and deprecating the MODE STREAM command. Implementations conforming to RFC 2980 will remain compatible since servers MUST still accept MODE STREAM.

interoperability-note §6

Use of the MODE READER command on a mode-switching server may disable the STREAMING extension. After MODE READER, the STREAMING capability may no longer appear in the capabilities list.

normative-requirement §2.1 SHOULD

A client MAY use an adaptive strategy sending TAKETHIS without CHECK if most articles are accepted (over 95% might be a reasonable threshold), and SHOULD switch back to using CHECK if the acceptance rate falls much below the threshold.

normative-requirement §2.5.1 MUST NOT

A client MUST NOT use the TAKETHIS command unless the server advertises the STREAMING capability or returns a 203 response to the MODE STREAM command.

normative-requirement §2.3.2 MUST NOT

A server MUST NOT require that the MODE STREAM command be issued by the client before accepting the CHECK or TAKETHIS commands.

normative-requirement §2.2 MUST

A server supporting streaming MUST continue to advertise the STREAMING capability after a client has issued the MODE STREAM command, and this capability MAY be advertised both before and after any use of MODE READER.

normative-requirement §2.4.2 MUST

For CHECK: if the server wants the article a 238 MUST be returned; if already held a 438 MUST be returned; if deferred a 431 MUST be returned. The first parameter of each response MUST be the message-id provided by the client.

normative-requirement §2.5.2 MUST

For TAKETHIS, the client MUST send the entire article (headers and body) as a multi-line data block. The server MUST return either 239 (success) or 439 (rejected); on temporary error it MUST reply 400 and close the connection.

normative-requirement §2.3.2 MUST

If a server supports this extension, it MUST return a 203 response to MODE STREAM (or 501 if an argument is given). The MODE STREAM command MUST NOT affect server state in any way.

normative-requirement §2.3 MUST

New clients SHOULD use the CAPABILITIES command to detect STREAMING support but MAY use MODE STREAM for backwards compatibility with legacy servers. Servers MUST accept MODE STREAM for backwards compatibility with legacy clients.

normative-requirement §2.1 SHOULD NOT

The client MAY send articles via TAKETHIS without first querying with CHECK, but SHOULD NOT do so for every article unless explicitly configured by the site administrator based on out-of-band information.

normative-requirement §2.5.2 SHOULD NOT

The client SHOULD NOT assume an article has been successfully transferred unless it receives an affirmative response. A dropped connection or 400 response SHOULD be treated as a temporary failure and retried later.

normative-requirement §2.4.2 MUST NOT

The responses to CHECK are advisory; the server MUST NOT rely on the client to behave as requested by these responses (i.e., the client may send articles via TAKETHIS regardless of CHECK advice).

protocol-element §2.4

The CHECK command informs the server that the client has an article with the specified message-id and queries whether the server wants it. Responses: 238 (send it), 431 (retry later), 438 (not wanted); message-id is echoed in all responses.

protocol-element §2.3

The MODE STREAM command is a legacy compatibility command that returns 203 if the server supports streaming. It MUST NOT affect server state and MAY be pipelined. Syntax: 'MODE STREAM'; single response: 203.

protocol-element §2

The STREAMING extension provides three commands (MODE STREAM, CHECK, TAKETHIS) and is advertised via the capability label 'STREAMING' in response to the CAPABILITIES command.

protocol-element §2.5

The TAKETHIS command sends an article (headers and body) to the server immediately after the command line. Responses: 239 (transferred OK) or 439 (rejected, do not retry); message-id is echoed in all responses.

registry §6

This document registers the STREAMING extension in the IANA NNTP Extensions registry with capability label 'STREAMING' (no arguments), defining three new commands (MODE STREAM, CHECK, TAKETHIS) and five new response codes (203, 238, 239, 431, 438, 439).

registry

security-consideration §5

No new security considerations are introduced by this extension beyond those already described in the core NNTP specification (RFC 3977). Implementers should consult RFC 3977 for applicable security guidance.

security

wire-format §3

All CHECK and TAKETHIS responses echo the message-id as the first parameter: 'response-238-content = "238" SP message-id', similarly for 239, 431, 438, 439. Command syntax: 'CHECK message-id' and 'TAKETHIS message-id'.

wire-format §2.5.2

TAKETHIS article data is sent as a multi-line data block immediately following the CRLF of the command line. A single '.' on a line terminates the block; lines beginning with '.' in the original text have that dot doubled during transmission.