Oh sorry. I thought I was approaching it as a clarification and not
really introducing any new functionality per se, i.e. simply fitting
what already exist hence why in the field it seems to work.
You said it yourself with your former opes chair hat on:
The OPES team looked long and hard for a way to break out
of the timeout situation and the "150-" situation really was
the best solution to get proposed, and it actually seemed
to work with current existing servers.
and added:
I'm not suggesting that this use be blessed within 2821bis.
However, I could easily see an extension I-D being written
that defines and blesses its usage. So I wouldn't want to deny
its possibility within 2821bis. I guess I'm falling into the
(ii) camp here.
But if with your 2821bis pseudo-chair hat on now feels it still make it
out of scope, then I throw up my hands.
--
HLS
Tony Hansen wrote:
<pseudo-chair hat on>
Adding language about a new 150 reply code in a multiline response would
be introducing new functionality to the spec and would be out of scope.
</pseudo-chair hat on>
Tony Hansen
tony(_at_)att(_dot_)com
Hector Santos wrote:
I would like to suggest one paragraph wording after the final paragraph
in 4.2.1:
Only the final or last reply-code is important in a multiline
response. The client MUST use the final line as the ultimate
server response. It is possible for a server to use a
preliminary reply code 150- as part of multiline response
with a final non-continuation completion code.