ietf-mxcomp
[Top] [All Lists]

Re: consensus call on pra/mailfrom deployment and versioning/scope

2004-09-09 11:38:05

Daniel Quinlan <quinlan(_at_)pathname(_dot_)com> wrote:

If patent-encumbered stuff (PRA) is any part of the specification
(and I see it mentioned in your proposal), then the ASF (including
the SpamAssassin and JAMES projects) vehemently objects.

Stephane Bortzmeyer <bortzmeyer(_at_)nic(_dot_)fr> writes:

Even if, while mentioned in the specification, it is optional and can
be ommitted at will?

Yes, I think so.  I understand the fine distinction you are trying to
make with this proposal, but it appears to be a back door (and I don't
think you are trying to be deliberately harmful to open source) for the
IETF to standardize a patent-encumbered technology in order to push
Sender ID out the door as soon as possible.  In the end, it would become
a de-facto requirement as the proposal stands.  Also, it is not certain
that the patent will be invalidated or that anyone will have the
resources to invalidate it, so relying on that strategy as part of the
reasoning for this proposal is not a valid argument.  Still, it's
possible the license will be fixed and this will become a moot point.
(I still would like to see the scope become modular as I noted in one of
my earlier technical last call comments.)

We want some method to parse RFC 2822 headers to be part of the
standard.  However, PRA is off limits to us due to how the license is
currently designed.  An unencumbered method to authenticate RFC 2822
messages that is permitted and encouraged is needed.  I believe that the
"experimental" PRA standard will end up an effective requirement,
especially given the intense campaign of the last few weeks to get
companies behind the encumbered standard.

Given that there is a lack of consensus on PRA, it seems like the
best course is drop PRA entirely and allow the specification authors
to revise things a bit more freely again.

Crypto-related standards (a field crippled with patents) often use the
very same method to allow interesting (but potentially infringing)
algorithms.

If the field of crypto is crippled with patents, are you keen on doing
the same to email?

See RFC 2246 for instance. You do not object against it because it
mentions the patented IDEA?

False analogy.  There are many alternatives to IDEA that do basically
the same thing and a bunch of them are mentioned in RFC 2246.  In
addition, nobody needs IDEA to authenticate email as best possible.  If
PRA is implicitly the way you connect RFC 2822 with Sender ID, then
email systems will be required to support it:

 - at send time, to conform with systems that use PRA at receive time
   (even when not desired)
 - at receive time, to conform with sites that only send with the PRA
   scope

It seems likely it will become a requirement by virtue of how it is used
and because there is no alternative being pursued by the IETF.  I think
we can find a way to resolve this (either replacing PRA with an
unencumbered alternative or an open license on the PRA patent(s)), but
relying on the patent going away is wishful thinking.

Daniel

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/


<Prev in Thread] Current Thread [Next in Thread>