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

[Jeffrey M. Vinocur]

On Wed, 4 Jun 2003, Ken Murchison wrote:

> Are existing implementations so rigid that they can't handle anything 
> other than:
> 
> NNN <message-id>\r\n

Both innfeed and innxmit are robust with regard to trailing text (innfeed 
takes the second whitespace-delimited word, and innxmit takes whatever is 
between the first < and the first > after that).  

But I'm very wary of breaking something.


> True.  Couldn't we just state that the message-id MUST immediately the 
> follow response code and that freeform text MAY follow the message-id. 
> Since a message-id has a well known syntax, is should be easy for a 
> client to find the end of it.

Clearly if we were introducing a new extension, this would be fine.  The
question is whether every single existing implementation can handle the
change.


> The only reason that I bring this up, is that it is sometimes useful to
> have a textual reason for a failure be part of the response.

Oh, I agree, in principle.  In fact, it's not clear to me that the set of
TAKETHIS responses we have is adequate for the client to actually know the 
disposition of the article -- but that's what we've got.

It would be possible to provide a clean alternative (like OVER replacing 
XOVER and such), but I'm not sure it's worth it.


-- 
Jeffrey M. Vinocur
jeff at litech.org