ietf-nntp DEBUG command & x9x (was: 9xx)

[Clive D.W. Feather]

Chin Chee-Kai said:
>>> * If the command doesn't have any multiline responses, assume that unknown
>>>   codes are not multiline.
> 
> I presume this is referring to multiline *data* responses in above.

Yes.

> So it cannot be assumed that current commands which give 
> one-liner *data* response will not have multi-line *protocol*
> response

At present it can be. And we were talking about how to handle the issue of
unknown responses, not how to add multi-line protocol responses.

> (if this were the case, it'd defeat the purpose of having
> multi-line mechanism for sending multi-line protocol response
> for whatever reasons, such as debugging, annotations, site-to-site
> administrative notes, etc).

I've come to the conclusion that NNTP is not the place for these; at least,
not in any conforming mode.

>>> * If all legitimate 2XX responses are multiline (I don't think we have
>>>   any multiline responses that *aren't* 2XX, do we ?), then assume that
>>>   an unknown 2XX is multiline, but nothing else is.
> This requires all clients to know what exactly is all known (and valid)
> 2XX response for each command.

No it doesn't.

Consider ARTICLE. All legitimate 2XX responses are multiline (there is only
one: 220). So a reasonable action would be to assume that all 2XX responses
to ARTICLE are multiline.

>>> * If some 2XX responses are multiline, but not all, it's harder.
> If "multiline" here means "multiline data response" (as per current
> RFC977), then, sure, examples are "BODY" and "HEAD".

Huh ? The only 2XX response for HEAD is 221, and for BODY is 222.

In fact, the only command with more than one 2XX response is MODE READER,
so there are no commands with both single- and multi-line 2XX responses.

For a short while I thought that every 2XX code was either single- or
multi-line, but regrettably 211 is found in both forms.

> If "multiline" here means "multiline protocol response", then,
> such response may occur for any and all commands as all commands
> are subject to debugging or annotations by the implementor.

Not at present they aren't.

>>> * You could send something innocuous and unusual, like DATE, then:
>>>   - if the next line of input begins 111, the odd response was on its own;
>>>   - otherwise the next line was multiline, so skip down to the dot.
> 
> Is this suggesting that "111" is a "non-multiline-marker"?

I'm suggesting it as a heuristic to determine whether or not the unknown
response was multiline.

> And, if the first line of input to the client is not "111", then
> where does the client stop interpreting the input lines as part
> of the meta-data protocol response or the actual data response?

When it sees the dot.

>>> * You could assume that any further lines will appear within 10 seconds,
>>>   so do a read with timeout on the socket.
> 
> If server needs to send only 1 protocol response line, does this
> mean now that the client must wait for more than 10 seconds to
> conclude that there's only a 1-liner response?

You appear to be misunderstanding what I'm saying.

If an unknown response is seen, what is the client going to do ? I'm
suggesting all the above approaches - including the 10 second timeout - as
ways to decide. If the response code is *known*, there's no need to do any
of this.

None of what I'm saying relates to your "nnn-" proposal, because I think
that's unworkable.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <clive at davros.org>  | Fax:  +44 20 8371 1037
Demon Internet      | WWW: http://www.davros.org | DFax: +44 20 8371 4037
Thus plc            |                            | Mobile: +44 7973 377646