--On Tuesday, August 02, 2011 09:07 -0400 Barry Leiba
<[email protected]> wrote:
>...
> In other words, I'm willing to put another month or two into
> it, as long as we're this far. If others (and the ADs) are
> with me, and John will send me the source code, I'll have at
> it.
Unfortunately, given other commitments, it could easily take me
a week or two to find the current source and edit out enough
personal comments that it would be suitable for sharing with
others.
One way or the other:
-- I recommend trying to sort out the "promises made to
various IESG members to get them to remove DISCUSSes
that did not seem to me to meet the IESG's published
criteria" issue that we discussed briefly during the WG
meeting. The revised document would be much less
different from 5321 and much less prone to errors
without them.
-- I note that several issues have come up since the
pre-eval document was approved whose proponents were
loud enough to suggest "new discoveries that are so bad
that they absolutely have to be
incorporated...". The appeal-prone debate about what
issues fall into that category could take up more time
than you anticipate.
Alternate suggestion if we are serious about this: someone who
cares what is in the document does a review of the archive in
the last 15+ months and any other outstanding issues that can be
identified and prepares a list of topics raised that didn't make
the earlier document. Based on that list, we have a discussion,
possibly even seeing if we can get consensus to update the
pre-eval document with a revised list.
Then, based on how that discussion goes and how well the "... so
bad that..." line can be held, we made a decision about revising
the document. By then, I might actually have time to do it,
leaving Barry's time free for other work.
Although it hasn't been a source of significant discussion in
YAM, as a start on that list, I note that we discovered in EAI
that the description of the extension model in 5321 does not
explicitly require that:
-- A client MUST NOT assume the availability of an
extension if the server doesn't announce it.
-- Clients that wish to use an extension that the server
does not announce MUST either (i) send the message in a
form that does not require any features of that
extension or (ii) abandon the SMTP session.
-- If the particular extension provides for a client
announcement that it is using a particular extension
(such announcements can take many forms depending on the
extension), the client MUST NOT send the announcement if
the server does not announce support for the extension.
The server MUST NOT assume assume the extension is in
use unless the client sends the announcement and MUST
either (i)handle the message according to the rules in
SMTP without the extension or (ii) reject the message.
I believe that, if it is not possible to agree on the
appropriateness of clarifying that issue, a 5321 revision is
hopeless.
john
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
