ietf-nntp draft-ietf-nntpext-streaming-00

[Jeffrey M. Vinocur]

On Fri, 6 Jun 2003, Clive D.W. Feather wrote:

> Jeffrey M. Vinocur said:
> >> Why the restriction on no freeform text in the responses?  This isn't in 
> >> RFC 2980, and also differs from IHAVE.
> > 
> > - I'm mostly trying to document current practice.
> 
> Is it really current practice?

As I said in my initial post, I have *no* idea what current practice 
actually is, and based this 00 draft solely on RFC 2980 and some quick 
glances at INN.

Certainly no one seems to be aware of any existing implementation that 
returns additional text after the message-id in CHECK/TAKETHIS responses.  
The question is whether clients are robust in the presence of such text.


> > - The responses have to contain the Message-ID, so what appears after
> >   the code matters.
> 
> That's nonsense.
> 
> Firstly, there are many other responses in the main NNTP document which
> contain significant data after the response code. Nobody seems to have a
> problem with this.

Maybe I wasn't clear -- 

My original reading of Ken's question boiled down to "Why do we have to 
have this message-id instead of actual text" so I was simply pointing out 
that it was important *to* have that data there.  I in no way intended to 
object to the practice of including important data after response codes!


>     The server MAY add any text after the response code or last parameter
>     as appropriate, and the client MUST NOT make decisions based on this
>     text. Such text MUST be separated from the numeric status indicator
>     or the last parameter by at least one space. 

Wow, I had missed that paragraph entirely (can you tell I haven't slept so 
much recently?).

Ok, so we're saying that the server can return any additional arguments it 
wants to any command it wants, without the specification for that command 
indicating that's the case?  If so, I certainly can't object to the same 
applying to CHECK and TAKETHIS.


-- 
Jeffrey M. Vinocur
jeff at litech.org