Hey Alexey - thanks for sticking with this:
<snip>
It will save developers and architects a lot of time in the future
to be explicit in the draft about that so they don't have to fight
long semantic battles with product managers.
While I can see the hypothetical situation you describe, most of the
developers/architects are quite naive (to say politely), so they
would be much better off not inventing something new, unless they
know what they are doing. The document is trying to save them the
troubles by showing 2 scenarios step-by-step.
But if you think that the document really need to state that example
scenarios are informative, I can add that.
I think it would help, but my input is just one LC comment voice. Take
that for what it is.
So adding "The document also defines a new IMAP extension and
registers some new IMAP keywords" after it doesn't look too bad.
(Just to confuse the matter: the keywords I am referring to in the
last sentence are not the CAPABILITY keywords you were talking about
earlier.)
I'm sure I introduced any confusion - sorry :)
5) Section 7 paragraph 2: Is this document attempting to
restate RFC4409 requirements or make new ones that are different?
It is trying to restate RFC 4409 requirements, but using stronger
language. Unfortunately RFC 4409 is a bit vague on this, so I
would rather leave the text as is.
If its just pointing out consequences of following 4409, I
strongly encourage you to rewrite this paragraph without using
2119 words. For instance, "When following the requirements
stated in [SUBMIT] a client will either connect to an
explicitly configured port at the submission server, or will
default first to 587. [SUBMIT] allows subsequent attempts at
other ports, including 25, if the initial attempt fails. See
[SUBMIT] for information on why using port 25 is likely to
fail ..."
In general, that's a very dangerous thing to do. Which document
defines the normative behavior? If [SUBMIT] really is vague on the
point, then there is an opportunity for different interpretations.
Here is what RFC 4409 currently says:
3.1. Submission Identification
Port 587 is reserved for email message submission as specified in
this document. Messages received on this port are defined to be
submissions. The protocol used is ESMTP [SMTP-MTA, ESMTP], with
additional restrictions or allowances as specified here.
Although most email clients and servers can be configured to use port
587 instead of 25, there are cases where this is not possible or
convenient. A site MAY choose to use port 25 for message submission,
by designating some hosts to be MSAs and others to be MTAs.
This text is targeted at operators/developers on mail submission
servers. It is not helpful to client developers.
So the text is explaining the exact procedure to be used by clients.
Another reason for this text is to make sure that clients allow to
connect to a port other than 25 for mail submission. Some existing
clients still don't.
If you feel really strongly that 4409 needs to be clarified,
consider an update to that document.
I would recommend that to authors of RFC 4409, sure. But I don't
think this document should block on such revision.
I was in no way suggesting blocking the document because of this.
I still (again, just as a single LC commenter voice) think you'd be
better off not using 2119 words here, and if you do use them,
explicitly acknowledge that you are not
trying to update 4409.
If you want to leave the 2119 words in this document, but aren't
intending to normatively update [SUBMIT], you should say exactly
that.
(I think that's what you're trying to do with the "explicit usage
of [SUBMIT] means that" qualifier, but I don't believe that's a
clear enough indication to most readers.)
Thanks!
RjS
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
