ietf-nntp Currently outstanding issues

[Russ Allbery]

Jeffrey M Vinocur <jeff at litech.org> writes:
> On Fri, 25 Apr 2003, Russ Allbery wrote:

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

I'm content with it; I don't think that constitutes a "use" in the sense
that that section means.  In other words, the client isn't blissfully
assuming that the server still has the extension; it's just warning the
user that the available extensions have changed.

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

I'm a bit confused by what you're saying here, since it sounds like you're
saying that you want the existing language (MUST over SHOULD) without an
exception, which would mean that servers supporting other commands are
completely non-compliant.

Could you clarify?

> 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;

Right, I don't like it either (but adding restrictive language to our
draft doesn't really help).

> 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 would be excellent.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>