ietf-nntp Currently outstanding issues

Ken Murchison ken at oceana.com
Fri May 2 14:01:01 PDT 2003


Jeffrey M. Vinocur wrote:
> On Fri, 2 May 2003, Clive D.W. Feather wrote:
> 
> 
>>   Keywords MUST be at least three characters and MUST NOT exceed 12
>>   characters. Command lines MUST NOT exceed 512 octets, which includes
>>   the terminating CRLF pair. The arguments MUST NOT exceed 497 octets.
>>+  A server MAY relax these limits for commands defined in an extension.
> 
> 
> Ah, much clearer.
> 
> 
> Query:  why can't we permit an extension to indicate the server supports 
> longer lines for existing commands?  (It seems like this could be useful, 
> and wouldn't break anything; clients not checking for that extension would 
> stick to the 512-octet limit, and smarter clients would only do so if the 
> server indicated that was acceptable.)

I think adding this to the protocol is overkill.  The extension document 
should indicate by how much the command/response length limits are 
increased by the presense of the extension.  Both clients and servers 
which implement the extension will already know ahead of time what the 
new limits will be.  The is what SMTP does for its extensions.  For 
example look a sections 3 for both RFC 2554 and RFC 1870.

> 
> Query:  do we want to specify the behavior of the server if a over-long
> command is received?  (In particular, of the four possible behaviors that
> come to mind -- (1) handle the long line, (2) return a syntax error, (3)
> treat the first 512 octets as a command ignoring the remainder, and (4) 
> treat the first 512 octets as a command and then treat the remainder as 
> the next command -- I'd like to require the server to do one of the first 
> two, and not one of the last two.)

I'd say (2).

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




More information about the ietf-nntp mailing list