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").
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.
It will also inform interop arguments.
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". 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.
If you feel really strongly that 4409 needs to be clarified, consider
an update to that document. 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
