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