Wayne, I wrote:
Until such time that there is at least a proof-of-concept code that
we
can all play with and collect real data on real email feeds, I will
strongly object to including the RFC2822 identities as something we
should work on.
This is a self-fulfilling, circular, kind of position don't you think?
It
is invalidated by the first sight of an implementation which uses these
identities... but you've ruled them out of scope already... So you
can't
have a MARID proposal which uses them...
No, this not any more a case of circular reasoning than saying that
you need to move the horse around to the front of the cart is circular
reasoning.
We're tasked with developing the record, there are NO current
implementations which use it, as it hasn't been developed yet. Our input
documents (and other inputs) are useful in considering identities, but they
don't describe systems which depend on the ouputs of this group.
This working group has a very agressive schedule. What I'm saying is
that I, personally, will have very little confidence in any algorithm
that be applied to billions of emails that hasn't had extensive
real-world testing.
Unfortunately, Wayne, what you said was "Until such time that there is [an
implementation] [you] strongly object to including the RFC2822
identities...". I'm sure you're right not to have a great deal of
confidence in something that hasn't had the kind of testing you suggest. If
you meant to say "Personally I don't like 'em, but don't take this as a
recommendation that 2822 identities should be out of scope", then you
failed to make yourself clear.
As an aside, it might be worth pointing out that 2822 "identities" are
extensively used as input to all kinds of "filtering" systems (often in
MUA, sometimes in association with rhsbl, etc) and there's a great deal of
experience out there.
Let's look at the milestones again:
March 04 Discuss identities [...]
April 04 [...] last call on which identities [...]
And now we're getting close to that 'last call for identities' and your
point is?
I think the time has long past for people to come forward with
handwaving descriptions of how validation might work. If the
algorithm hasn't been defined and tested by now,
I'm not sure what you're proposing here, time travel?
there is no way we
will get through the discussion of semantics in a month.
In which case the schedule may change. Have you never worked on a project
like that? It's not the end of the world, but it does call for some real
project (and client relationship) management. Sometimes we drop features,
or otherwise trim the product, to hit deadlines. Other times we tweak the
schedule because there's no advantage in delivering a broken product
(however promptly).
Given that we're tasked with developing "a DNS-based mechanism for
storing and distributing information associated [with authorization]",
which is not limited to the primary current use case, there is no obvious
requirement that any dependent (anti-spam) implementation should currently
exist.