Hi John/Dave, sorry I missed the chat today...
--John Leslie <john(_at_)jlc(_dot_)net> wrote:
In the jabber session, Dave Crocker suggested we are aimless:
resnick: I argued that we should do "all of them", i.e. design a
mechanism that can handle HELO, MAIL FROM, and 2822.
dcrocker: "let's do everything" is only slightly worse than "let's do
multiple". either way, it says that we do not really know
what we are trying to accomplish or why.
jlcjohn: I disagree -- we have very good reasons for each.
dcrocker: oh? I think I'm missing a clear statement of those "good
reasons", in a fashion that lets us see incremental,
long-term benefit. I say long-term because this level of
standards work cannot ever do anything that is "interim".
jlcjohn: happy to discuss in detail on list...
This seems to be a bit circular. Semantically it boils down to this.
Q: Well I think we should design a mechanism to do all three things.
A: Hang on, doing multiple things is bad, doing all things is worse.
Q: But there are good reasons for each.
A: If there are good reasons for each, and they are all important, how can
we do something that is incremental?
Q: Hmm. You want something incremental? I suppose if we have a flexible
mechanism, we could do one thing first and the other stuff later...
A: Wait, this is a standards working group, you can't do anything "interim".
Q: Well, if we can't do anything "interim" then we should design a
mechanism to do all three things.
A: Hang on, doing multiple things is bad, doing all things is worse.
Q: WTF? you want something that is incremental but not interim? That's
like attacking the "everything" idea as "too broad" and at the same time
attacking the "do one first" idea as too narrow!
Looks like I get to start this discussion...
First of all, we're in a context where we're clarifying our charter:
none of these comments should be taken to mean what comes first.
Dave would like us to lay out what we're trying to accomplish: I'd
like to see that too; but I don't believe there's any reason to worry
about reaching consensus on that yet. It will become an important
question as we set about designing what should go into our first RFC.
My disagreement (during the jabber session) with Dave was whether
such a choice would "say" we don't know what we are trying to
accomplish.
I agree with this. "I want multiple things" is quite distinct from "I
don't know what I want". If anyone chooses to read what we want and why,
and infer that we aren't clear on what we want, or that the message is too
vague, we can't really help that. Those of us within the working group
should agree first, before publishing anything to the outside world, so
that we are publishing a consistent message.
My point was that we have very good reasons to want to design
DNS records relating to HELO authorization, equally good reasons to
want DNS records relating to RFC2821-MAIL-FROM, and good, though
different, reasons to want RFC2822 authorization info. They don't
need to be the same reason.
[snip of three perfectly good reasons.]
I agree that all of them are good targets. We are therefore faced with a
choice. [Yes, I know you said "we should not decide *yet* what to do
first, just what is important" so we can defer this discussion for another
time, but deciding what to do first will need to be done eventually :)]
1. Do everything at once. Publish one RFC that covers it all. This is
really the only way to make sure that all targets are served *and* the
mechanism used for each is consistent.
2. Do one thing at a time, and make a best effort to use a mechanism for
the first that could also cover the second and third. Accept the risk that
the mechanism may not be as extensible as we had hoped and either needs
changing/extending in the second/third rounds or some goals may not be met.
An in-between choice would be to publish a draft for one target, and let it
receive public comment while we work on the second part, and the first one
could advance to the next approval stage about the time the second draft is
ready...
Personally I could go either way. I *really* think it would be *great*
boost for the group to come up with a MAIL FROM validation scheme first,
and that would provide some attention, some kudos, and some encouragement
to tackle really hairy issues like From:/Sender:. Taking that a step
further, we could even choose to validate HELO first, since it may be
somewhat easier, but I don't think it would provide as much immediate
relief and positive notice to merit releasing it first.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>