ietf-nntp Currently outstanding issues

[Clive D.W. Feather]

Russ Allbery said:
> Can I get a status update on this?

Sorry; I had a major attack of Real Life at both work and home and keep
putting less urgent things off "until tomorrow". As you can see, I'm
starting to catch up.

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

Okay, so we can ignore that one and take the answer to be "no".

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

Nor am I. On the other hand, if there *isn't* an issue, then why do we want
undocumented commands to begin with an X? Either there is an
interoperability issue or there isn't. If there is, what is it? If there
isn't, why is SHOULD appropriate?

What I think we're *actually* trying to do is ensure that future standard
extensions don't conflict with experiments or locally-defined commands. In
which case I don't think SHOULD is the right word.

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

All of that says to me that we're flogging a dead horse. If we're not going
to have a register of names in use (and I agree that it's overkill at this
stage in the game), then I think all we need to say is that the standards
process MUST NOT use X* and rely on the relatively small development
community to co-ordinate among themselves. Perhaps add some wording saying
that you SHOULD use X* until ready to document it for wider use.

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