I have a slightly different viewpoint of Microsoft's possible strategy and thus
the risk forward.
Microsoft does not need to patent SPF and/or PRA in order to make it irrelevant
in future. All they have to do is make all their programs that process e-mail,
do it in way that the anti-forgery information can only be extracted via using
their patent. Then we are all stuck licensing their patent and following their
standard. They could even re-write e-mails in transist with SPF info into
CallerID encumbered headers.
My intuition is there is a reason the algorithm for CallerID is so complex and
my intuition says it is not because that is the best algorithm to use.
Getting "internet standard" seal on it, helps protect them against lawsuit, so
they can proceed unencumbered to use their monopoly in clients to eventually
wrest away the control that GPL has on the server.
So we most need to worry about losing our ability to sue Microsoft, not the
other way around.
If I were Microsoft, I would have every influential member of IETF WGs in my
back pocket.
So what can we do? Not much. We do not control the clients. We do not have
the influence in the IETF.
I for one, am trying to pre-empt any anti-forgery on the client. I think
everyone here would prefer to ignore the client marketshare issue at their own
demise.
Now - please tell me I am wrong - but if M$ are applying for a patent
licence over the CORE and PRA documents (or parts of them), it is going to
be impossible to *not* include the PROTOCOL document - which is spf .
No, not in my understanding. Remember, MS applied for the patent(s) for
CallerID, not for SenderID, and only parts of CallerID at that. They
applied for their patents before MARID even got started, so the patents
are
not based on MARID documents -- they only overlap to the extent that the
final documents contain parts similar to the original CallerID.
[...]
They may end up getting patents for various things, some of which are
needed to implement SenderID, and some of which aren't. It looks like the
license only applies to inventions that are *both* covered by an MS patent
*and* necessary to implement SenderID.
[...]
In other words, they are not trying to steal SPF and patent it too. That
wouldn't work and even if USPTO granted it, it would be easy to challenge.
Heh - you got deep pockets? It'd be more than we could afford collectively,
just to get the defense assembled, let alone presented in court.
[...]
so
my guess is that it's *highly unlikely* that they would take Meng's
already
semi-derivative work and the work of others and try to patent it. I think
Anne is saying that is *possible*, but I am willing to proceed on the
assumption that MS is not trying to patent all of SenderID. They are not
getting money from the license, after all, just defending against rival
claims.
I agree. Sender ID is aimed more at MUAs anyway, so it
isn't that big a deal if MTAs have trouble with it --- it's
simply not that relevant to MTAs. What MTAs need to pay
attention to is Unified SPF which will be unencumbered and
is already well on its way.
In which case why is it being considered by (and developed in) the
"MTA Authorization Records in DNS" Working group? If it is aimed at
MUAs and is not relevant to MTAs then it should be rejected (or should
already have been rejected) as being off-charter.
[...]