ietf-nntp AUTHINFO SASL protocol choices

Jeffrey M. Vinocur jeff at litech.org
Tue Mar 26 11:08:52 PST 2002


Ok, getting back to this...

On Mon, 18 Mar 2002, Charles Lindsey wrote:

> In <Pine.LNX.4.33.0203170033410.2129-100000 at marduk.litech.org> "Jeffrey M. Vinocur" <jeff at litech.org> writes:
>
> >Ah, ok.  I have no strong preference here.  Other people?  Should we be
> >specifying how extensions should increase the line length limit?  If so,
> >should the number be documented in the output of LIST EXTENSIONS or in the
> >spec for the extension?
>
> I think you keep the flexibility. If you have an extension known as
> 	LENGTH1024
> which just increases the present 512 to 1024, then there will come a time
> then someone wants 2048 for whatever reason, so they have to invent yet
> another estension.
>
> Whereas if you invent an extension for arbitrary lengths (to be specified
> as a parameter) then implementors can decide how long they will support,
> and clients can find out using the LIST EXTENSION command.

I've been thinking about this.  I think the best way thing is to be
flexible.  That is, the extensions mechanism should, in a general way,
permit extensions to increase the line length limit.  Then if some
extension (say, one which adds a new command) only needs 1024, the spec
for that extension can simply say that it needs lengths of at least 1024.
If some other extension needs to increase the current maximum by some
amount (say, one which adds new parameters to existing commands), it can
say that it needs lengths of, say, 256 more than the amount dictated by
all of the other commands.  And any extension which wants the ability to
increase its limit is free to use a parameter for that purpose; the
extensions mechanism need not dictate that such a parameter must exist, I
think.


> Since the extension mechanism in our draft makes provision for extensions
> to have parameters, we may as well make use of it.

Right.  So if we do the above, we can (and probably should) have a LENGTH
extension with a parameter showing the server's maximum length.  Then
clients can, if they like, simply use the server's maximum.  On the other
hand, if a client wants the smallest maximum which allows a particular set
of extensions to be used, that can be hardcoded by reading the
specifications for those extensions.



If this sounds good, I will write up some text for the changes to the
draft (and perhaps also for the LENGTH extension as well, although not
immediately).


-- 
Jeffrey M. Vinocur
jeff at litech.org




More information about the ietf-nntp mailing list