The IETF MARID WG co-chair wrote:
Given this, it is the opinion of the co-chairs that MARID should not
undertake work on alternate algorithms reasonably thought to be
covered by the patent application.
wayne <wayne(_at_)midwestcs(_dot_)com> writes:
Uh, can you give an example of an alternative algorithm to the PRA
that has been discussed that might be "reasonably thought to be
covered by the PRA patent"? I can't think of any.
As per RFC3668, which all participants of this mailing list are
supposed to comply with, if we start creating an alternative that does
happen to be covered by any IPR of any other participant, we will
learn about such encumbrance.
See:
http://www.ietf.org/NOTEWELL.html
http://www.ietf.org/rfc/rfc3668.txt
So, while I agree that we shouldn't try to create a standard that we
know is encumbered, isn't this pretty much what we have been trying to
do already?
I would also like to hear the answers to Wayne's above questions.
(I agree with the point he is trying to make.)
It is the opinion of this participant that the pra scope will not
reach consensus due in large part to the patent mess, whether there is
a mailfrom scope or not.
Agreed. If "mailfrom" is the only other scope, then I suspect Apache
SpamAssassin, Apache James, and perhaps other open source
implementations will wholly reject Sender ID.
Maybe that's what some people want. I'm perplexed by this whole
direction.
It is the opinion of this participant that the mailfrom scope will not
reach consensus. unless it also allows for the helo scope to be
checked and thus be compatible with SPF-classic. SPF-classic is the
current defacto standard and I think standardizing existing practice
is the easiest way to reach a consensus.
Agreed, a "helo" scope should be explored.
Given this work plan, I do not expect this working group to ever
produce a first specification. *very heavy sigh*
I disagree with this. I think we might produce a specification that
will be largely ignored or succeed in handing a major part of the
internet to anyone who brings patented technology into IETF standards.
I don't mean to be inflammatory, but those are the only two *likely*
outcomes I can see for the current plan:
- the specification doesn't happen or is ignored
- email authentication is owned by (the patent holder) since (the
patent holder) can change the revocable patent license in the future
It's *possible* the patent(s) will not be granted, but I prefer to avoid
relying on things outside of my control as much as possible.
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/