--Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com> wrote:
I also believe that there is a difference of approaches here - some
people want to approach this with a single identity in mind. Others want
ability to choose different identities and mechanisms like SPF does. Yet
others, want ability to extend this into a more generic "server
configuration description" language. Determination of scope would be
helpful.
I agree. I would like to see a relative narrow focus for the first
milestone (such as announcing authorized outgoing servers and refuting
others) and I'm willing to delay some of my other desired goals (such as
declaring other policies, examining other headers, having more flexible
mechanisms).
I think it would be a good thing for the working group to announce an early
success in a limited area, than to spend a longer time coming up with
something more feature-rich.
In other words, I am a big fan of SPF, but I would support something less
extensible, if it could be folded into an RFC sooner.
Now. That said, I would like "being extensible in general" to be a goal as
well. There are other milestones to come, and if we choose an
implementation that is as streamlined as possible for specifying outgoing
servers, but can't be extended to add other mechanisms or other policies,
we basically have to start all those other efforts from scratch.
So I guess I am saying:
Most important: Ability to easily specify outgoing servers and refute others
Next most important: Implementation that could be used for other purposes
later is preferred over one that can't
I think it's appropriate to discuss our other goals, and kick around some
ideas and some ways that they could be complementary to our first goal, but
we should not have to agree on all the other possibilities in order to get
to our first milestone. We can determine a scope for the first milestone
(first RFC) and not necessarily rule out discussion on other topics.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>