Subject: Microsoft Claimed IP, License Terms, etc.

From: Nick Shelness <[email-masked]>
Date: Sun, 29 Aug 2004 11:27:21 +0100

All,

I don't really want to enter this discussion, but I believe it is 
necessary.

For those that don't know me, I'm the ex-CTO of Lotus (98-01) and thus 
someone who professionally had to spend a great deal of time (too much) 
worrying about IP issues, and consulting with IP lawyers. I was also the 
source of a private suggestion to Harry Katz that [E]SMTP be extended to 
identify the email submitter as an alternative to mucking about with RFC 
[2]822 headers. At the time, Harry indicated that this idea was new to him 
and Microsoft. I leave it to Harry to indicate whether he has subsequently 
encountered a prior claim to this idea.

Now to the nub of the issue.

Microsoft has disclosed that they claim to possess Intellectual Property 
(IP) that must be utilized to implement the in-process-of-development IETF 
standards described in draft-ietf-marid-core-03.txt, 
draft-ietf-marid-pra-00.txt, and their successors. This disclosure is 
required as a precondition of Microsoft (employees) involvement in the 
development of these in-process-of-development IETF standards. They are 
not required to disclose specifics of the IP they claim to posses, merely 
that they claim to possess it.

This disclosure in no way establishes the validity of this claim. This 
awaits the issuance of a patent or patents, and the subsequent defense of 
this patent or patents. Any individual or organization is free to write to 
the patent authorities in any and all jurisdictions claiming that IP that 
they believe has been submitted for patent protection is covered by "prior 
art" or is "obvious", both of which are grounds for rejection of a patent 
application. The patent authorities can also determine that IP that has 
been submitted for patent protection is covered by "prior art" or is 
"obvious" on their own, but in the US they are constrained by a number of 
adverse judgements that restrict their ability to so do.

Given the above, an individual or organization wishing to implement and 
distribute code that supports the processes defined in 
draft-ietf-marid-core-03.txt, draft-ietf-marid-pra-00.txt, and their 
successors, has to determine the strength of Microsoft's, and other 
potential, and as yet undisclosed, IP claims. This is unfortunate, but is 
a feature of the current software development landscape.

In the case of the Microsoft IP claims, Microsoft has offered to waive any 
and all of their claims with respect to IP required to implement the 
in-process-of-development IETF standards described in 
draft-ietf-marid-core-03.txt, draft-ietf-marid-pra-00.txt, and their 
successors, on a royalty-free basis in exchange for execution of a license 
agreement. I recognize that there potential problem with this licence, 
especially with respect to its non-extension to sub-licences.

So, net, net, implementors have three choices.

1. They, with the help of their advisors, can determine that Microsoft, 
and as yet unknown others, possesses no IP that would encumber an 
implementation of draft-ietf-marid-core-03.txt, 
draft-ietf-marid-pra-00.txt, and their successors. Based on such a 
determination, they can then proceed apace. They might of course be liable 
to subsequent claims for redress from Microsoft, and as yet unknown 
others, if this determination proved subsequently to be in error.

2. They, with the help of their advisors, can determine that Microsoft, 
and as yet unknown others, do possesses IP that would encumber an 
implementation of draft-ietf-marid-core-03.txt, 
draft-ietf-marid-pra-00.txt, and their successors, but can further 
determine that Microsoft, and as yet unknown others, are highly unlikely 
to make claims for redress. Based on such a determination, they can then 
proceed apace. 

3. They, with the help of their advisors, can determine that Microsoft, 
and as yet unknown others, do possesses IP that would encumber an 
implementation of draft-ietf-marid-core-03.txt, 
draft-ietf-marid-pra-00.txt, and their successors, and in order to receive 
protection from subsequent claims for redress from Microsoft enter into a 
licence agreement with Microsoft that grants them the right to employ the 
claimed IP. They can then proceed apace. 

The IETF (marid wg) also has a number of choices.

1. Encourage Microsoft to more precisely identify their claimed IP so that 
implementors could make a more informed judgement with respect to its 
"obviousness" and coverage by "prior art". My guess, is that this IP is 
limited to determining whether the PRA as defined by the PRA algorithm is 
consistent with the sending SMTP client's IP address. My sense is that 
"prior art" can be found for determining the PRA - it's implicit in RFC 
822, but not for whether the PRA is consistent with the sending SMTP 
client's IP address.

2. Limit the scope of marid to the [E]SMTP MAIL FROM: command, with or 
without the SUBMITTER parameter. RMX, SPF, etc. which operated on the MAIL 
FROM: address almost certainly constitute prior art, and I am the source 
of the proposal to Microsoft that [E]SMTP be extended to identify a 
submitter, and gladly waive any and all rights, etc. Sadly, their may 
other earlier claims to the idea of extending [E]SMTP.

3. Attempt to find a non-PRA based approach to verifying the message (SMTP 
DATA) content.

The above does not propose a solution to the problem at hand, but I hope 
at least lays out the alternatives that may be pursued by 
implementors/marid.

Nick Shelness
Independent Technology Consultant <[email-masked]>

---

From: Hadmut Danisch <[email-masked]>
Date: Sun, 29 Aug 2004 15:47:08 +0200

On Sun, Aug 29, 2004 at 11:27:21AM +0100, Nick Shelness wrote:
> application.

Thanks for that information. I'm not familiar with the US procedures
to do so, so could you (or anyone else) give me details about how to 
do this (address, formal requirements, costs,etc.).

> their may 

I do remember that something like this has been discussed earlier, 
before MS published CallerID. The discussion was (I'm not sure until 
I've searched my archives, but I think I raised the discusssion) about
the fact, that the sender address does not need to have the meaning of 
a 'sender' or 'submitter' for RMX and RMX-alike proposals. Actually it 
is just an abstract, meaningless pointer to any domain providing 
a record covering the sender's IP address. As far as I can remember 
I have proposed somewhere to just run the message header against a
regular expression and use just everything, which looks like an 
e-mail address to find a domain covering the sending host, and allow
the sender to include just any arbitrary header line to include an 
appropriate e-mail address. 

Your/Microsoft's proposal is different in the way that it places the 
'pointer' in the MAIL FROM:-command instead of the message header. 
But from my point of view this is far away from reaching the invention
depth required for a patent. Even without the discussion I mentioned
I'd consider this idea as trivial (once RMX was published), and not 
sufficient for a patent. 

And, not to offend you, but to give my honest opinion: 

Claiming a patent on such a minor and trivial 'invention' is unworthy
of any serious software company. Given the fact that Bill Gates was 
still talking about making e-mails expensive and digital stamps a few
months ago, Microsoft must face the question why they didn't invent 
anything on their own, but need to abuse such trivial
'microinventions' to hijack other people's ideas. 

Hadmut Danisch

---

From: "Harold A'Hole" <[email-masked]>
Date: Sun, 29 Aug 2004 08:50:09 -0700

Isn't it nice to know that any software we write can be so encumbered and
restricted by unknown agents who claim they invented and own some processing
logic so you can't use that logic yourself?  Patents protect innovation in
software so well.

Perhaps this shows once again that the IETF would do better to adopt
existing protocols that have been field proven before they try to make them
into standards.  Let the code and process logic be in the public domain for
a few years, see how it really works (or doesn't) and let enough time pass
to find out if there are any torpedo patents lurking (they should all have
been granted or rejected, or at least published after that much time).

Harry

---

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 29 Aug 2004 09:47:48 -0700 (PDT)

> encountered a prior claim to this idea.

It is nice to have confirmation that idea of SUBMITTER did not come from 
Microsoft. On this I'll note that there are alternatives available to 
current CallerID system which take major parts from it, including
SUBMITTER and authentication of external (independent network-network) 
connections and establishing party responsible for introduction of 
processing of email for each such network, but this does not use PRA 
algorithm and would probably not be bound by Microsoft IPR claims (hard to 
confirm these things when you dont know what exactly they claim is invented)

Since chairs specifically asked not to discuss any alternatives to CallerID
until we decide on current set of documents based on last call, I will not
be mentioning any details, but if you do like the parts of CallerID approach
mentioned above but believe IPR claims and other tech issues are significant
that CallerID should not go forward as is, this does not mean the whole 
approach is necessarily dead and the only options are envelope bounces-to 
(the so called envelope "mail-from") and EHLO identities and that RFC822 
From and what is shown to MUAs can not be protected by MARID design. 

At the same time, I also believe that protecting just one idenity and
designing protocol such that is so specific to just that idenity with
no support for scoping and other identities is bad, if we put aside 
current documents which were done in way too much haste (they leave too 
many technical issues and errors unresolved and should probably not go 
forward even if there was not such an IPR controversy) then we may have 
opportunity to work on more complete approach to authentication of email 
session with help of DNS records which is what MARID was charted to do.

I'm also leaving below some other parts of the email I replied to which
are relevent to what I just wrote above.

---

From: "David H. Lynch Jr." <[email-masked]>
Date: Sun, 29 Aug 2004 23:01:52 -0700

>'microinventions' to hijack other people's ideas. 

    I was about to ask regarding that too. I thought that there was a 
set of requirements to determine if something was patentable.

    Something to the efect that it has to be implimentable - You are not 
supposed to be able to patent ideas only implimentations of them, the 
fact that software is so close to the
pure expression of the underlying idea is one of the strong arguments 
against software patents.

    I think some of the other requirements are no published prior art, 
uniqueness, novelty, usefullness, and non-obviousness.

    I think Hadmut's reference to this being a trivial micro-invention, 
is approximately equivalent to saying that it is obvious.

    I am also not sure how verifying the PRA actually even constitutes 
an invention much less a patentable one.
    But if Microsoft is filing 20,000  patent applications a year I 
would imagine that an awful lot of them have to be  pretty trivial.

    Software patents are an evil aspect of life that has to be dealt 
with atleast until it becomes more obvious that they have failed - not 
in the theoretical sense of being a bad idea
    but in the practical sense of having become totally unworkable.

    There are not things I will give Microsoft the benefit of the doubt 
on. But my guess is their massive patent portfolio effort is more 
deffensive than offensive. 
    I do beleive they are capable of using IP to try and disadvantage 
FOSS. As evil as that sounds it is also legitimate. The purpose of 
patents is to prevent the competition from
    capitolizing on your invention. To Microsoft FOSS is the 
competition. But for the most part Microsoft's IP record has been mostly 
defensive and not offensive.
    Further, trying to actively use IP to disadvantage FOSS is a 
dangerous and counterproductive step. The FOSS community may or may not 
have deep pocket litigation
    resources depending on the particular issue. But the prior art 
research resources available to FOSS are enormous. Someone somewhere at 
some time must have atleast discussed
    some form of verification of Sender addresses in a public mail list 
or newsgroup.