Re: why we should not be ambiguous about receiver behaviour

["Jon Kyme" <jrk@xxxxxxxxxxxxxx>]

> >>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.