Hi Robert,
Robert Sparks wrote:
inline
On Feb 21, 2009, at 4:44 PM, Alexey Melnikov wrote:
<snip>
2) It's not clear whether the Forward without Download section is
intended to be "Here's a couple of ways you can realize this
feature if you have all the tools this profile requires available
to you" or "If you are going to realize this feature, please do it
this way" or "You MUST choose one of these ways if you are going
to realize this feature".
I don't think the difference between 3 variants really matters. A
combination of Submission and IMAP servers allows the client to use
either approach.
If a client writer can invent a third approach based on advertised
extensions, I would be impressed ;-).
While a 3rd variant may be highly unlikely, unless you are really
wanting to close the door on using one if it shows up, you should
make a statement
about whether you intend these to be the methods to *be exactly what
people implement or that they are examples of how these tools might
get used*.
I think I'm hearing that the later is really what you mean (though
you're saying "almost certainly will because their the natural
choice" where I said "might").
Right.
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.
It will also inform interop arguments.
I don't think there is an interop issue either way: a compliant server
has to implement all pieces, so it would work correctly with both
clients that implement scenario 1 or scenario 2.
It would help to make the abstract, introduction, and the first
part of section 8 more explicit. Similarly, the draft is
registering a keyword to use in a CAPABILITY response - it would
help if the abstract and section 5.7.1 made this very explicit.
Actually section 3.2 lists the URL-PARTIAL capability in the table
of required extensions, so I think this should be clear already.
I don't understand your response - were you talking about the last
comment I made above (about being more explicit that the draft is
registering a new keyword?). If so, I don't think I made my point.
I'm looking for a sentence in the abstract that says something like
"This document registers a new keyword for use in CAPABILITY responses".
Which is the same as saying that "This document defines a new IMAP
extension ...".
Ok, I should have been clearer on this in my first reply. I thought this
didn't belong to the Abstract, because it would have been an unnecessary
clutter.
I also think that people who are going to look for what is included in
the Lemonade Profile will find everything in sections 3.1, 3.2 and 3.3;
and people who are looking for this extension by name can find it in the
IANA registry for IMAP extensions.
However, on a second thought, the Abstract already says:
The Lemonade profile relies upon several extensions to IMAP and Mail
Submission protocols.
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.)
If you were responding to something else, please clarify.
<snip>
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.
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
