Subject: [NNTP] Proposed changes to draft-ietf-nntpext-streaming-02

From: ken at oceana.com (Ken Murchison)
Date: Wed Nov 3 08:54:30 2004

Changes from Previous Version:

   New:
   o  Added "Command Continuation" section.

   Changed:
   o  Replaced uses of "asynchronous" with "pipelined".
   o  Wording used in MODE STREAM examples.
   o  Removed (ill-advised) 432 response code as a temporary failure for
      TAKETHIS.  Replaced with discussion of 400 response for temporary
      failure.
   o  Changed reference to IANA requirements in [NNTP] from Section 8 to
      Section 8.1.

Outstanding issue:

    o Do we want to add any discussion of the server issuing a 400 (or
      maybe a 403) response to TAKETHIS?

Relevant text diff:

@@ -224,7 +208,7 @@
  .fi
  .LP
  .ne 4
-2.2. Asynschronous Article Transfer
+2.2. Pipelined Article Transfer
  .IP
  The STREAMING extension provides the same functionality as the IHAVE
  command ([NNTP] section 6.3.2) but splits the query and transfer
@@ -297,16 +281,16 @@
  .ne 4
  2.3.3. Examples
  .IP
-Example of a client requesting the ability to stream articles from a
-server which does not support this extension:
+Example of a client checking the ability to stream articles on a
+legacy server which does not support this extension:
  .in 8
  .nf
  [C] MODE STREAM
  [S] 501 Unknown MODE variant
  .fi
  .IP
-Example of a client successfully requesting the ability to stream
-articles:
+Example of a client checking the ability to stream articles on a
+legacy server which supports this extension:
  .in 8
  .nf
  [C] MODE STREAM
@@ -399,7 +383,6 @@
  .in 8
  .nf
  239 message-id   Article transferred OK
-432 message-id   Transfer failed; try again later
  439 message-id   Transfer rejected; do not retry
  .fi
  .IP
@@ -409,7 +392,7 @@
  message-id = Article message-id
  .fi
  .IP
-The first parameter of the 239, 432, and 439 responses MUST be the
+The first parameter of the 239 and 439 responses MUST be the
  message-id provided by the client as the parameter to TAKETHIS.
  .LP
  2.5.2. Description
@@ -423,9 +406,8 @@
  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, a 432 response, indicating that the
-transfer failed but should be tried again later, or a 439 response,
-indicating that the article was rejected.
+was successfully transferred or a 439 response, indicating that the
+article was rejected.

  This function differs from the POST command in that it is intended for
  use in transferring already-posted articles between hosts.  It SHOULD
@@ -444,7 +426,8 @@
  The client SHOULD NOT assume that the article has been successfully
  transferred unless it receives an affirmative response from the
  server.  A lack of response (such as a dropped network connection or a
-network timeout) SHOULD be treated the same as a 432 response.
+network timeout) or a 400 response SHOULD be treated as a temporary
+failure and cause the transfer to be tried again later if possible.

  Because some news server software may not be able immediately to
  determine whether or not an article is suitable for posting or
@@ -500,7 +483,8 @@
  [C]
  [C] This is just a test article.
  [C] .
-[S] 432 <[email-masked]>
+[S] 400 Service temporarily unavailable
+[Server closes connection.]
  .fi
  .LP
  .ne 4
@@ -525,7 +509,19 @@
  takethis-command    = "TAKETHIS" WS message-id
  .fi
  .LP
-3.2. LIST EXTENSIONS responses
+3.2. Command Continuation
+.IP
+.nh
+This syntax extends the non-terminal "command-continuation", which
+represents the further material sent by the client in the case of
+multi-stage commands.
+.IP
+.nf
+command-continuation =/ takethis-continuation
+takethis-continuation = encoded-article
+.fi
+.LP
+3.3. LIST EXTENSIONS responses
  .IP
  This syntax defines the specific LIST EXTENSIONS responses for the
  STREAMING extension.
@@ -569,13 +565,6 @@
  Meaning: transfer not possible; try again later.
  .fi
  .IP
-Response code 432
-.in 8
-.nf
-Generated by: TAKETHIS
-Meaning: transfer failed; try again later.
-.fi
-.IP
  Response code 438
  .in 8
  .nf
@@ -600,11 +589,11 @@
  6. IANA Considerations
  .IP
  This section gives a formal definition of the STREAMING extension as
-required by Section 8 of [NNTP] for the IANA registry.
+required by Section 8.1 of [NNTP] for the IANA registry.

  .in 8
  .ti 5
-o  The STREAMING extension provides for asynchronous transfer of
+o  The STREAMING extension provides for pipelined transfer of
  articles.

  .ti 5

-- 
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

---

From: rra at stanford.edu (Russ Allbery)
Date: Thu Nov 4 22:10:02 2004

The proposed changes to all three of the drafts look good to me.

>       maybe a 403) response to TAKETHIS?

I think so.  Here's some suggested text:

    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.

I'm nervous about the effect of 403 on existing implementations, but
probably wouldn't object strongly if it were added as an additional
alternative here, like:

    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 either a 403 or a 400 response to the client.  A
    400 response (which is followed by the server closing the connection)
    is recommended if the error is likely to affect all subsequent
    attempts to transfer articles as well.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: ken at oceana.com (Ken Murchison)
Date: Fri Nov 5 09:05:00 2004

>     attempts to transfer articles as well.

I'll hold off on adding text about 403 until we hear from Andrew on 
this.  If we don't discuss 403, I might combine your two versions into 
something like:

"If the server encounters a temporary error that prevents it from
processing the article (such as disk full) but does not want to reject 
the article, and the error is likely to affect all subsequent attempts 
to transfer articles, it MUST reply with a 400 response to the client 
and close the connection."

The point being that if the error only affects the given article 
(however unlikely), closing the connection seems unfriendly.

---

From: rra at stanford.edu (Russ Allbery)
Date: Fri Nov 5 19:21:31 2004

> processing the article (such as disk full) but does not want to reject the
> article, and the error is likely to affect all subsequent attempts to
> transfer articles, it MUST reply with a 400 response to the client and
> close the connection."

> (however unlikely), closing the connection seems unfriendly.

If we don't discuss 403, closing the connection is the only option the
server has though.  Doesn't 400 require an immediate close?

---

From: ken at oceana.com (Ken Murchison)
Date: Fri Nov 5 19:57:33 2004

> server has though.  Doesn't 400 require an immediate close?

Yes.

The reason I'm hesitant to document 403 (I'm now wondering why I 
mentioned it) is because it seems to be a deferral code on this case and 
we've already decided that they don't make sense after the server 
receives the article.

---

From: rra at stanford.edu (Russ Allbery)
Date: Fri Nov 5 20:35:59 2004

> we've already decided that they don't make sense after the server

Yeah.  The other problem with 403 is that I believe it's an innovation in
our draft, like 401.  INN currently never produces either of those
response codes.