Re: Invalid channel numbers

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>>> How do you send back a response for the condition that you couldn't
>>> parse the request to the point of finding the channel number to use
>>> in the response?
>> There is no such condition, because if you can't parse the request,
>> you have no request to respond to [...]
> Does the spec say this anywhere?

Not specifically, but the spec does describ the syntax of channel
requests.  If the circumstance arises, either your request parsing is
severely broken or the sender's request generation is severely broken.
In either case, interoperability problems are only to be expected.

> I can see an implementation hanging while waiting for a response to a
> request that'll never arrive if you don't send it back at least some
> sort of response.

So can I.  But if it happens for this reason, it's the fault of the end
with broken code, and arises because of that broken code.  No matter
what we do, we can't make the protocol robust in the face of excessive
implementation brokenness.

>> You can of course send a "you sent me something I couldn't make head
>> nor tail of" error, but that's very different from an error response
>> to a channel-specific request.
> The only error message mechanism that I can see if you can't send a
> request-failed response is a full disconnect, which is rather drastic
> if there are (for example) valid data transfers in progress on other
> channels at the time.

Yes, it is.  But no more drastic than the sender sending a request so
badly mangled as to be unparseable - or, as the case may be, your
parsing code being so broken as to be unable to parse a valid request.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B