[NNTP] CAPABILITIES problem!

[Kai Henningsen]

chl at clerew.man.ac.uk (Charles Lindsey)  wrote on 03.08.05 in <IKn61y.8IJ at clerew.man.ac.uk>:

> In <87ack0nvlb.fsf at windlord.stanford.edu> Russ Allbery <rra at stanford.edu>
> writes:
>
> >I have no idea why there's a limit either.  We've had a limit, as Ken
> >noted, for the entirety of this process, but I don't know why it was added
> >in the first place since RFC 977 doesn't have one.
>
> Life is always simpler with strings of a known maximum length (no need to
> malloc space every time a new string is encountered). For simple keywords,
> intended primarily for internal protocol use, a fixed length is quite
> enough. Unlimited length is really only needed to suit the convenience of
> human readers/writers (which might apply in the Capabilities case, but not
> for command names).

But note that a keyword length limit in the standard does nothing  
whatsoever to help you there.

First, there obviously is a maximum length to the set of keywords you  
actually understand. If you want to take advantage of such a length, you  
already have a candidate length.

And second, there's no way a rule in the standard can prevent the other  
side from trying to use a longer string, so you already have to be able to  
cope with that.

> Note that the only effect of the current restriction is to constraint
> authors of future extensions (which might simplify parsers).

Again, no. Changing that maximum length doesn't make the parser either  
simpler or the opposite.


MfG Kai