spf-discuss
[Top] [All Lists]

RE: Article on Microsoft patents and Caller ID

2004-10-13 20:04:33
This is what Meng had to say about 3 weeks ago.

Guy

-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of Meng 
Weng Wong
Sent: Tuesday, September 21, 2004 7:24 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Article on Microsoft patents and Caller ID

On Tue, Sep 21, 2004 at 10:28:37AM -0400, guy wrote:
| 
| This list has been told that you have an agreement with Microsoft.
| What can you tell us about your agreement with Microsoft?
| If you are not allowed to say anything, then say so.  But I would like to
| know anything I can about the deal.

In January, the industry asked Microsoft and me to resolve
the differences between Caller ID and SPF.

Working together, we reduced the differences to three issues:
1) format: XML vs SPF txt
2) identity: PRA vs mail-from/helo
3) what forwarders do: prepending Resent-From vs SRS

We were unable to resolve these differences, so we agreed to
disagree.  In May, after tepid industry acceptance of the
XML format, Microsoft asked if I would like to try again.
We met in Washington, DC at a MAAWG event, where Microsoft
proposed:
1) ditch the XML format and use the SPF format
2) introduce SUBMITTER (then called RFROM) to make PRA
   available at envelope time
3) I also recall from the meeting that a receiver would be
   allowed to assume that if SUBMITTER was not present, then
   MAIL-FROM could be considered to be the PRA at envelope
   time, and rejections would be permitted before DATA: this
   provided essential compatibility with SPF Classic's
   semantics.

   However, I may recall incorrectly.  In any case that part
   of the agreement seems to be of questionable unanimity.

Further to that, we agreed to jointly write up proposals for
the above ideas under the name of Sender ID and submit them
to the IETF.

I did not agree to abandon SPF Classic.  In fact, as soon as
it became apparent that the Microsoft interpretation of
Sender ID would not consider MAIL-FROM as a fallback when
SUBMITTER was absent, I tried to get MARID to reintroduce
MAIL-FROM to Sender ID; and most recently we seem to have
succeeded.  At any rate spf2.0 records now allow mail-from
scopes to attach to the prefix string, so receivers can
check the mail-from identity independent of the PRA which is
known to be patent-encumbered.

All of these agreements were verbal.  No contracts were
signed, and no money has changed hands between Microsoft and
me, aside from them paying for my plane ticket to Redmond in
May, and from them paying for my hotel room in August.

So I'm not sure what kind of "deal" people have in mind, and
I'd sure like to know what they think happened.

If I have been relatively quiet on the MARID list, it is
mostly because it seemed to me more polite to disagree
privately with people you have a working relationship with.

| 
| The reason I ask, maybe Microsoft now owns SPF?

Nobody in the SPF community gave or sold SPF to Microsoft,
though I have a hard time imagining how anyone can own an
idea jointly constructed by an group of opensource
developers and working group members.

Well, I lied.  There is one way that someone can own SPF, at
least in the United States and in other jurisdictions which
recognize US patents or where which Microsoft has filed for
a patent.  If Microsoft owns SPF, it will be because a
government body has assigned Microsoft a statutory monopoly
on ideas in the sender authentication space which overlap
with SPF.

Keep in mind the irony that patents were originally created
as a way to increase the public good, by giving inventors
incentive to invent by collecting profits from their
inventions.  They must have overlooked the case where
inventors want to invent anyway, are happy to give away
their inventions, and aren't interested in getting profits
out of them.

I don't think the people who invented patents foresaw the
situation where patents could be used as a weapon against
the public good, by prohibiting inventors from freely
distributing their inventions.

I therefore suggest that if people want to keep any one
corporation from owning the concepts behind SPF, concepts
which seem to be an essential part of the future of email,
then they should dedicate their efforts to that end.  They
can start by learning about how the patent process works,
reading the patents very carefully, looking for examples of
prior art, thinking of ways to work around the claims that
are most likely to be approved by the USPTO, and
contributing those workarounds to the public domain.

No, wait!  Don't contribute those workarounds to the public
domain just yet.  You need to patent them first, because if
you don't, somebody else will, and then we'll find ourselves
in the same mess all over again.

I think that means that even if you can think of an
unencumbered way to work around the patent, you still
shouldn't talk about them in any public forum, including the
IETF and spf-discuss.  Maybe that's why the MARID list has
been so quiet lately.

Hmm.  It looks like patent law has managed to achieve the
exact opposite of what it was meant to do.  Maybe this is a
sign that patent law is broken.

OK, so don't disclose your workarounds to the public
domain.  Talk to me privately about them, and I will help
you patent them; and then I will help you preserve them for
freedom and the public good.  Only after we have them patented
can we disclose them to the open community.  Welcome to the
ironic side of the 21st century.

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features
SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription, 
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com


<Prev in Thread] Current Thread [Next in Thread>
  • RE: Article on Microsoft patents and Caller ID, guy <=