[Top] [All Lists]

rfc2821bis status report

2007-04-28 11:06:58

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.


Attachment: RFC2821bis-status.pdf
Description: Adobe PDF document

<Prev in Thread] Current Thread [Next in Thread>
  • rfc2821bis status report, John C Klensin <=