Here's my take on the NOOP definition, and guidelines for last call
comments further on.
I do have a *slight* problem with the current wording in that
If a parameter string is specified, servers SHOULD ignore it.
also means that servers "MAY pay attention to what's in the string". A
server issuing a 421 in an attempt to say "the service is no longer
available to you at this time" technically meets the spec.
IF were were going to make any change, I'd say it should be changed to:
If a parameter string is specified, servers MUST ignore it.
Period. Full stop. Nothing more needs to be added.
But even so, a server is *still* free to issue a 421 at any time. I
could see a service doing this because it recognizes some particular
behavior of the client based on behavioral observations, which *include*
looking at the strings passed on NOOP commands, and decides that the
best thing to do when a certain gestalt is reached is to close down the
channel. It can even choose to issue a bogus random reason string if it
chooses, including one that says "the command is too long :-) ".
So would this change make any difference operationally between a server
and a client? No, not one bit.
So I withdraw even that suggestion.
Now, as the document *is* in Last Call, bringing up issues with the
document ARE allowed and encouraged. The purpose of the comments need to
be constructive and not open ended. And they should be oriented towards
the interoperability of the protocol. They should include specific
suggestions for change. These comments may even cause the document to be
reopened before being issued as an RFC; after all, the reason for having
a Last Call is to get any final issues out in the open and fixing Last
Call comments is part of the process.
Any and all issues *must* be passed through the filter of: will this
change enhance or harm the interoperability of the protocol?
Tony Hansen
tony(_at_)att(_dot_)com