ietf-nntp Currently outstanding issues

[Clive D.W. Feather]

Jeffrey M. Vinocur said:
>> | OUTSTANDING ISSUE
>> | Should the initial response line be limited to 512 octets as well? [...]

> (Hmm, you might want to point out here that an extension could "increase
> in the maximum length of commands over the value specified in this
> document" [section 8] -- or is that being silly?)

It can't quite be done like that. What I've done is:

   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.

and:

   The first or only line of the response MUST NOT exceed 512 octets,
   which includes the response code and the terminating CRLF pair;
+  an extension MAY specify a greater maximum for commands that it
+  defines, but not for any other command.

> I just noticed something:
> | An NNTP client MUST NOT cache (for use in another session) any
> | information returned if the LIST EXTENSIONS command succeeds.
[...]
> In the SASL draft-to-be, I believe we indicate that a client might be wise 
> to cache this information in order to display a cautionary message to the 
> user should a high-security method be missing (perhaps indicating a 
> cipher downgrade type attack).

I don't consider that as caching (i.e. temporary storage of a copy of data
in order to avoid the need to re-fetch or re-compute it). The practice is
fine, but I suggest you find a different word to describe it (e.g. "... to
record this information ...").

>> Section 8:
>> | OUTSTANDING ISSUE
>> | As worded, this forbids commands like MODE SLAVE that servers already
>> | provide but that aren't part of an existing extension. We can't simply
>> | make these illegal.

> I mean, is saying that a server
> that supports other commands (particularly AUTHINFO) can only be
> "conditionally compliant" necessarily a bad thing?

I feel that what we've got isn't internally consistent. I don't have good
text to replace it yet, though.

> therefore an extensions
> document based directly on the parts of 2980 that are still relevant --
> which would be quite easy to write -- could be forthcoming soon.

That wouldn't be unreasonable.

>   - new client, old server -- the client can use MODE STREAM without
>     checking LIST EXTENSIONS first, just like now

But if it *does* check, it will get an error!

> Random formatting comment:  the table of contents is pretty unwieldy
> (particularly in the txt version), perhaps we can do something about that?  

The table is generated automatically by the xml2rfc package. I've stepped
it down to only include the first three levels; this means that some
commands have the Usage/Description/Examples structure shown and some
don't. I could fix that, but only at the cost of adding unnecessary
subsections.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646