John C Klensin wrote:
Hector,
One small clarification, just to be sure we understand where we
disagree, if at all. I am not proposing this, just trying to
understand...
Suppose 2821bis were clarified in just the way I think you have
been arguing against. In other words, it clearly said:
(i) In a multiline reply, all lines MUST use the same
reply code.
(ii) 1yz reply codes MUST NOT be sent by a server unless
they are specified by a specific extension that
overrides this provision of the specification for a
specific purpose.
(iii) multiline replies MUST NOT be used as an attempt
to affect client timing or timeouts.
I hope everyone understands that nothing in 2821 prevents an
extension from being designed, proposed, and adopted that, if
appropriately agreed to between server and client, changes any
or all of those rules. If 2821 is not clear on that topic,
then it should be and I would welcome appropriate text for
2821bis.
To the extent to which the concern is that making these rules
more specific (or implied prohibitions more clear) in 2821bis
would prevent such extensions, I think we need to clarify that
the concern is groundless.
Does that bring our positions closer together?
If I understand the question, you are saying that an I-D proposal can
update and even go as far as change an RFC and my "assumption" that it
can not is an incorrect assumption?
It is my understanding that an proposal can propose changes to current spec.
But I have a hard time answering that because whether you believe it or
not, I am extremely pragmatic and conservative. I don't want to break
operations for anyone nor for us. Thats the last thing I want.
Here is my opinion above the above items:
I think it would be mistake to have above, but I can see the benefits of
locking it down. I am for 100% technical clarity and 100% SMTP
compliant. I don't (iii) is necessary because it is SUBJECTIVE plus you
have no control over this usage.
If you write into stone the above three clarifications, I extremely
doubt anyone will have the incentive to do any more beyond that because
if they do, they will begin to break systems. I know I wouldn't want to
go there. Paraphrase: It would have to be an extremely groundbreaking
new concept viewed as having a high acceptance and high adoptability
aspect to it before I would want to waste time on such a new proposal or
even consider it for implementation.
Throwing aside all the IETF regulations for "ratifying" this new RFC,
I frankly believe this is a natural element of the protocol and ideally
should be part of this document for one reason - it is compatible for
most systems and those are are not compatible are technically
non-compliant with not just 2821bis but also 821.
But I can understand the IETF restrictions or framework you guys are in
for this 2821bis work. I do understand. So all I can do is hopefully
structure my input as best as I can to make it a consideration. If not,
so be it.
At this point, maybe Hansen had the best (personal hat on) advice:
"don't do anything now that would prevent such an extension
from being written."
--
HLS