ietf-smtp
[Top] [All Lists]

Re: rfc2821bis-01 Issue 17: all contination lines must use same code

2007-04-11 06:40:32

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


<Prev in Thread] Current Thread [Next in Thread>