Hi.
I've just done a review of the state of the document compared
with what needs to be done, the original "charter" note, etc.
These comments are only the personal opinion of the editor, but
I think we are at a fork and need to decide about what we want
to do and why.
We are, IMO, down to one major, substantive, issue, which is the
matter of how to handle NDNs in 2821bis in the light of various
models of sender authentication and what is going on in the rest
of the world. Note that is a question about what should be done
with 2821bis, not a question about the general subject matter.
That distinction is very important, in part because of
constraints on the "2821bis to Draft" plan: independent of
debates about their merit, many of the ideas that have been
proposed would take 2821bis back to Proposed or earlier. As
just one example, if one adopts some flavor of "no NDNs except
to authenticated senders" rule, then I think one must discuss,
probably normatively, how one does the authentication and what
is adequate or not. One may also need to address techniques
(such as the one Hector proposed) for keeping an incoming
sender->relay connection alive while getting information about
what the relay->NextHop transaction would do. Any such changes,
other than the vaguest of hand-waving, would almost certainly
constitute new work (of the "return to Proposed" variety) as far
as 2821bis is concerned. I don't believe that inserting vague
hand-waving just to evade the document advancement rules would
benefit anyone (others may disagree, of course). This subject
turns up on the issues list (never version attached, in PDF
form) as Issue 25 but has spillover effects on several others.
As I read the rules for advancement, any changes to the document
at this point must represent either (i) removing material,
especially material that has not be implemented, (ii)
clarifications to existing text that don't change the protocol
as generally understood when 2821 was published, (iii) changes
that reflect current existing practices _and_ that are
consistent with what is already in the text. Those are _very_
strong constraints.
The other issues listed are, IMO, mostly trivial or cosmetic, at
least in the sense that I've heard no arguments that the
problems they are trying to fix are severe enough that they have
led to massive confusion and/or difficulty in getting
implementations that interoperate.
Issues 2 and 10 are in sort of a gray area: they do get close to
interoperability issues. I'm waiting for text from Ned but, if
we take the second path below, I probably understand the issues
well enough to make something up if we conclude that text won't
show up soon enough.
Anyway, I see two possible paths from here onward.
(1) We decide that we really need to get this document
as nearly perfect as possible, changing the ABNF to some
elegant and normative form rather than using it as
explanation of the syntax of commands, fixing even small
typographic and formatting errors wherever they are
found, adjusting terminology for complete consistency
and minimizing of possible confusion with other
documents, and continuing to find areas in which the
text isn't clear enough to be proof against bizarre (or
at least a little strange) interpretations. In each
case, we get to argue about the best way to address the
issues that are identified and then apply the new text.
That probably implies a year or three of work (at a
somewhat more leisurely pace). It is up to the ADs, but
I think anything with that sort of object and timeframe
probably requires a formal WG, with all that implies.
Some people, notably Frank, have made strong arguments
that such an effort is worthwhile and the timing is to
be expected.
(2) We decide that our goal is simply to get something
out that cleans up the obvious and serious problems in
2821. The main goal of that effort is to provide a
better referencing base for a number of documents that
are in progress now. That list presumably includes
pieces of the EAI and Lemonade work. Perhaps it also
cleans up issues needed to put work on OPES-like
activities, the family of things that include SPF and
DKIM (and other heavy and lightweight approaches to
header, sender domain, or sender validation and/or
authentication or authorization), and perhaps some
future extensions, onto a better foundation than 2821
provides. In that case, we are ready, I believe, to
resolve that key problem in some way, quickly clean up
the rest of the issues list, and adopt a "showstoppers
only" model to introduction of any new issues.
At some level, I don't have much of a preference. But I think
we need to decide RSN about what we are trying to do here.
john
RFC2821bis-status.pdf
Description: Adobe PDF document