ietf-nntp Currently outstanding issues

Russ Allbery rra at stanford.edu
Sat Jul 5 14:15:56 PDT 2003


Clive D W Feather <clive at demon.net> writes:
> Russ Allbery said:

>>> I believe that all open issues are now covered in "OUTSTANDING ISSUE"
>>> blocks.

>> I'm going to make statements of the resolution that I think all of
>> these outstanding issues should have.  If anyone *disagrees*, please
>> speak up.

> Given it's been a week, I'm going to start editing these in.

Can I get a status update on this?  We've gone silent for a while now, and
I'd like to put in that last push and get things finished off.  (Plus,
we're behind on our milestones.)

I'm snipping everything from your message that I agreed with.

>> | OUTSTANDING ISSUE
>> | This isn't a complete solution to the 480 issue;
> [...]
>> | The best proposal made so far is that all 48x codes, if returned from an
>> | existing command, mean "unavailable unless some authentication or
>> | privacy extension is invoked". Does this tie in with the issue of
>> | permitting existing commands not listed in an extension?
>> 
>> I think that's the right way to go.  The issue of not permitting existing
>> commands not listed in an extension we need to get into also; I don't
>> think that this ties in.

> I want to think further on this but, in the meantime, does anyone use
> 48x codes *with existing commands* to mean anything other than "you are
> missing an authentication or privacy extension"?

The only case that I know of where that happens is with the obsolete
XGTITLE command, which uses 481 as its error code (following the old rule
of using x8x for extensions).  This should not be a problem in practice,
as XGTITLE is completely replaced by LIST NEWSGROUPS with a wildmat and is
not something that we'll ever standardize.

>> 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.  (MODE STREAM
>> is the example that you want, I think.)

> I'm still thinking about this. The problem with a SHOULD is that it makes
> it impractical to rely on from a client point of view.

Does a client care?  In other words, why is it important for a client to
rely on the fact that there are no other keywords except those in the
standard and those beginning with X?  I'm not sure I understand the usage
scenario.

> In trying to solve this, how much can we force servers to change?

If the command has actually been deployed so that people are using it on
the wire, I don't think we can force people to change.  We certainly can't
change MODE STREAM (although that one will shortly be a non-issue since
we're going to standardize it).

For future extensions, I think we can probably require that people use X
until they get some sort of document written, provided that we're good
about accepting those documents.  The problem with requiring that things
be standardized before they get "good" names is that if the
standardization process is not responsive, people will just ignore it.  In
the past, the NNTP standardization process has not been responsive.  Maybe
we can improve that.

>> Section 8.6:
>> | OUTSTANDING ISSUE
>> | There is ongoing discussion about whether this extension should have a
>> | parameter and, if so, what it means.
>> 
>> Let's go with Ken's proposal here, for a LIST HEADERS command plus a
>> parameter that says all headers are provided.

> I haven't completely caught up with that discussion; I'd like a chance to
> do so before agreeing or objecting.

Certainly.  Please do speak up if you see any problems with the LIST
HEADERS proposal.

>> Section 12:
>> | OUTSTANDING ISSUE
>> | Why RFC 1939?
>> Stan answered this somewhere back in the list archives.

> I'll look.

> <FX: delay>

> It influenced how he laid out the original draft. On that basis, I think
> it should come out.

Given that we've pretty much completely reorganized at this point, I have
no problems with that.

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




More information about the ietf-nntp mailing list