ietf-nntp Currently outstanding issues

[Jeffrey M. Vinocur]

On Fri, 25 Apr 2003, Russ Allbery wrote:

> Clive D W Feather <clive at demon.net> writes:
> 
> >     http://www.davros.org/nntp-texts/draft18.txt
> >     http://www.davros.org/nntp-texts/draft18.html


> Section 3.1:
> 
> | OUTSTANDING ISSUE
> | 
> | Should the initial response line be limited to 512 octets as well? [...]
> 
> Yes.  

Agreed.  

(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?)

I just noticed something:

| An NNTP client MUST NOT cache (for use in another session) any
| information returned if the LIST EXTENSIONS command succeeds. That
| is, an NNTP client is only able to get the current and correct
| information concerning available extensions at any point during a
| session by issuing a LIST EXTENSIONS command at that point of that
| session and processing the response.  [section 5.3.2]

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).  The first sentence above seems to prohibit 
that usage, but then the second seems to be more acceptable.  Are we happy 
with the wording as is?


> 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.
> | 
> | The wording about starting keywords with an X could be reduced to a
> | SHOULD, except for backwards compatibility (with a pointer to RFC
> | 2980). But is that the right answer?
> 
> If anyone else has any better ideas, speak up.  Otherwise, we should go
> with SHOULD plus an exception for backward compatibility.

I definitely prefer MUST to SHOULD.  I don't love the idea of hardcoding
this exception for posterity, though.  I mean, is saying that a server
that supports other commands (particularly AUTHINFO) can only be
"conditionally compliant" necessarily a bad thing?

And I don't like the fact that authors has no option but to work from
2980, complete with a mix of never-really-implemented, now-standardized,
and not-standardized-but-still-in-use commands; 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.  Since we
don't require a client send LIST EXTENSIONS before trying to use an
extension, it works out really nicely regardless of whether client or
server is not aware of the existence of the standard and these extensions.  
Consider extension "STREAM" specifying the MODE STREAM exactly as per 2980:

  - old client, old server -- everything is exactly as at present
  - old client, new server -- the server is prepared to answer LIST
    EXTENSIONS but the client just goes right ahead without that, which
    is fine under the standard
  - new client, old server -- the client can use MODE STREAM without
    checking LIST EXTENSIONS first, just like now
  - new client, new server -- the client can check or not as it wishes

We'd just have to put a note in this extensions document explaining that 
if the server doesn't implement LIST EXTENSIONS, MODE STREAM may still 
work (and in fact, the client doesn't even need to try LIST EXTENSIONS if 
it doesn't want to).


(That's just off the cuff, I don't really feel strongly about it.)




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

  - indentation of lines for subsections
  - blank lines in between major sections
  - don't list page numbers for the lowest level of subsection (since 
    they're several-to-a-page it's not exactly tricky to locate one)
  - list the page numbers for all contents entries, but only include
    the dots on major sections
  - don't list the lowest level of subsection at all


-- 
Jeffrey M. Vinocur
jeff at litech.org