Arnt Gulbrandsen wrote:
Alexey Melnikov writes:
It is, but I would rather avoid specifying any limit in the document,
because it is likely to be exceeded in the future.
If it's big enough, I'm sure you can say "may be exceeded, although
unlikely".
But I guess the document can specify an absolute minimum and allow
implementations to support bigger line lengths.
Isn't that what RFC 1869 section 4.1.2 does?
I would like to see text saying something like "no implementations are
known to support line lengths greater than 12288
That is not true, Isode's implementation allows for 98304 :-)
and it is thought unlikely that any SASL mechanisms will ever require
longer line lengths".
I've just reread the text already in the document:
Note that these [BASE64] strings can be much longer than
normal SMTP commands. Clients and servers MUST be able to
handle the maximum encoded size of challenges and responses
generated by their supported authentication mechanisms. This
requirement is independent of any line length limitations the
client or server may have in other parts of its protocol
implementation.
and I think it is good enough. If an implementation only supports
CRAM-MD5, there is no reason to have 12K buffer for it, 1K would be
sufficient.
If people insist, I can add something like the following:
At the time of writing of this document, 12288 is considered to be
sufficiently big line length limit for handling of deployed
authentication
mechanisms.