AMBROSIA60 Portal  

 
| | News | Sitemap | Startseite | Kontakt | Impressum |

Project: Webinterface II - Msgbase Structures: Zvon - RFC 2980 [Common NNTP Extensions] - Transport Extensions

AMBROSIA60-Portal  Webinterface II Project
ZVON > RFC Repository > RFC 2980
Prev | Next |

2. Transport Extensions

   A transport extension is one which is primarily used in inter-server
   communications.  Following are the descriptions of each transport
   extension commands and the responses which will be returned by those
   commands.

   Each command is shown in upper case for clarity, although case is
   ignored in the interpretation of commands by the NNTP server.  Any
   parameters are shown in lower case.  A parameter shown in [square
   brackets] is optional.  For example, [GMT] indicates that the
   triglyph GMT may present or omitted.  A parameter that may be
   repeated is followed by an ellipsis.

2.1. The CHECK command

   CHECK <message-id>

   CHECK is used by a peer to discover if the article with the specified
   message-id should be sent to the server using the TAKETHIS command.
   The peer does not have to wait for a response from the server before
   sending the next command.

   From using the responses to the sequence of CHECK commands, a list of
   articles to be sent can be constructed for subsequent use by the
   TAKETHIS command.

   The use of the CHECK command for streaming is optional.  Some
   implementations will directly use the TAKETHIS command and send all
   articles in the send queue on that peer for the server.

   On some implementations, the use of the CHECK command is not
   permitted when the server is in slave mode (via the SLAVE command).

   Responses that are of the form X3X must specify the message-id in the
   response.

2.1.1. Responses

      238 no such article found, please send it to me
      400 not accepting articles
      431 try sending it again later
      438 already have it, please don't send it to me
      480 Transfer permission denied
      500 Command not understood

2.2. The MODE STREAM command

   MODE STREAM

   MODE STREAM is used by a peer to indicate to the server that it would
   like to suspend the lock step conversational nature of NNTP and send
   commands in streams.  This command should be used before TAKETHIS and
   CHECK.  See the section on the commands TAKETHIS and CHECK for more
   details.

2.2.1. Responses

      203 Streaming is OK
      500 Command not understood

2.3. The TAKETHIS command

   TAKETHIS <message-id>

   TAKETHIS is used to send articles to a server when in streaming mode.
   The entire article (header and body, in that sequence) is sent
   immediately after the peer sends the TAKETHIS command.  The peer does
   not have to wait for a response from the server before sending the
   next command and the associated article.

   During transmission of the article, the peer should send the entire
   article, including header and body, in the manner specified for text
   transmission from the server.  See RFC 977prop, Section 2.4.1 for
   details.

   Responses that are of the form X3X must specify the message-id in the
   response.

2.3.1. Responses

      239 article transferred ok
      400 not accepting articles
      439 article transfer failed
      480 Transfer permission denied
      500 Command not understood

2.4. The XREPLIC command

   XREPLIC ggg:nnn[,ggg:nnn...]

   The XREPLIC command makes is possible to exactly duplicate the news
   spool structure of one server in another server.  It first appeared
   in INN.

   This command works similarly to the IHAVE command as specified in RFC
   977prop.  The same response codes are used.  The command line arguments
   consist of entries separated by a single comma.  Each entry consists
   of a news group name, a colon, and an article number.  If the server
   responds with a 335 response, the article should be filed in the news
   group(s) and article number(s) specified in the XREPLIC command line.
   If the server cannot do successfully install the article once it has
   accepted it, a 436 or 437 response code can be used to indicate the
   failure.

   This command should only be used when the receiving server is being
   fed by only one other server.  It is likely that when used with
   servers that have multiple feeds that this command will frequently
   fail.

   XREPLIC slaving has been deprecated in INN version 1.7.2 and later.
   INN now has the ability to slave servers via transparent means,
   simply by having the article's Xref header transferred.  (In previous
   versions, this header was generated locally and stripped off on
   outgoing feeds.)

   It is likely that future versions of INN will no longer support
   XREPLIC.

2.4.1. Responses

      235 article transferred ok
      335 send article to be transferred.  End with <CR-LF>.<CR-LF>
      435 article not wanted - do not send it
      436 transfer failed - try again later
      437 article rejected - do not try again


ZVON > RFC Repository > RFC 2980
Prev | Next |



AMBROSIA60 News RSS 2.0 feed [Valid RSS]
Future4Fido
[ Join Now | Ring Hub | Random | << Prev | Next >> ]

©WebRing Inc.
FidoNet World Wide WebRing
<< Prev | Ring Hub | Join | Rate| Next >>
www.CAcert.org
SSL Powered
© 2003-2017 by Ulrich Schroeter Besucherzaehler