ietf-nntp Currently outstanding issues

[Russ Allbery]

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

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

It's so that we can always standardize a new command without conflicting
with a widely-deployed experimental command.  It's also so that we can fix
up various nits when we standardize the command, like we have with OVER
and HDR, without worrying too much about backward compatibility.

> Either there is an interoperability issue or there isn't. If there is,
> what is it? If there isn't, why is SHOULD appropriate?

The interoperability issue is that we'll standardize new commands without
regard (at least ideally) to any non-standard commands that don't begin
with X, so if one uses such a command, one may find that the behavior
suddenly has to change.  However, there are reasons to do this under some
circumstances (like using a command that's about to be standardized), so
MUST isn't applicable.  I think SHOULD is about right.

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

Do you still feel that way given the above argument?

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

I think that's an excellent alternative and would have no problem with
language along those lines.

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