[Top] [All Lists]

Re: New Issue: NOOP clarification

2007-11-29 18:17:17

John C Klensin wrote:

This is my last note on this issue unless you can present a
succinct and focused argument as to why this is sufficiently
important that we should reopen the document, risking having the
IESG suspend the Last Call, etc.  However, since this note is
(finally) the sort of focused discussion about the issue that I
(and I think others) have been looking for (and for which I
thank you), I want to respond directly to it.


I would allow you to be the judge if my response is a succinct and focused, and I will respect this is you last note. I hope my response can also be the last note as well.

Maybe simply this change to the last sentence of the NOOP
command section is appropriate:

  If a parameter string is specified, servers MUST ignore
the string as a reason for a 421 response. It MAY be
>>   used for logging purposes only.

This is helpful in that it is a specific proposal, with a
specific justification... and one that avoids distractions with
the many sub-issues.

However, my reading and understanding of the specification in
2821bis is that there is one and only one valid "reason for a
421 response" and that is imminent shutdown or disconnect.
Because one implementation has violated the specification by
issuing a 421 when that reason does not apply does not, for me,
justify reopening the document or inserting this text.

+1, but I suggest this is based on the premise they are not correctly 2821, and not on a premise they are following 821 (incorrectly as well).

Look at this. I went back to the same customer server using Microsoft ESMTP look at this:

220 XXXXXXXXXXXX Microsoft ESMTP MAIL Service, Version: 6.0.3790.395
9 ready at  Thu, 29 Nov 2007 16:25:47 -0800
EHLO LocalHost
250 OK
250 2.0.0 OK
421 5.5.2 Syntax error (command line too long)

Anything longer than 1 character produces an error. It would be interesting to know how current is this Microsoft ESMTP server.

Buggy?  Of course.  Did the MS programmer mis read the specs?  Who knows.

Now, for the record (because I don't think this is a significant
enough issue to justify reopening the document, but YMMD and you
can try to convince others), I'd be fine with

        If a parameter string is specified, servers MUST ignore
        that string. It MAY be used for logging purposes only.

I'd be fine with applying that same statement to RSET and QUIT
if their syntax permits strings at all.

+1. I didn't want to go that far, but if you think that helps makes it worth the effort. I'm all for it.

I just think that if it happened now, therefore it can potentially happen with other or new developers. So the question is why? and what can 2821bis do to help minimize any potential ambiguity, help new developers and also help old developers see something interesting and say "hmmmmmmm, I need to fix that NOOP."

Note that it doesn't say a think about 421, which I think
> is a distraction as well as a clear violation of the spec.
> I don't think it is necessary because I think that principle
> is clear from existing text.  But I don't think it is
> harmful either and,

and honestly that has been my mindset all along.

Please understand that I am under the belief that a major purpose of 2821bis was "codify" the specification to existing practice, to help clear ambiguious areas, with maximum effort to reduce any temptation to promote code changes. And I very aware of the idea that the 2821bis is in last call, and the only reason I even bother was 100% because I saw other recent suggestions being opened up to add/make further "clarifications". e.g., Null Return Path Abuse issues.

So I thought it might be ok to make the rather simplistic suggestion.

In hindsight, it was over simplistic and I apologize for the thread's wasteful length caused by me not being more specific with the original post. That was important to provide.