On Fri, 10 Jun 2005, Hector Santos wrote:
------------------------------------------------------------------------
IPR Disclosure: Algorithm I described above for doing path authorization
after forwarding based on hostname from crypto signatures is patent
pending. License is expected to be compatible with GPL programs.
-----------------------------------------------------------------------
Oh no, another Patent Terrorist!
Read the paper, it has more specifics why I'm doing. My personal opinions
are that patents in software are bad, but I'm not happy how they are being
used to squash the open-source (i.e. see MARID), the purpose is to protect
the use of technology for everyone, not the other way around as you seem to
think. If this comes down to standardization, I'd be happy to give the patent
to ISOC as long as others whose work is part of the standard do the same.
Two food crumbles to pick up and nibble on:
RFC 2821 already states it is possible for path authorization to take place
AFTER the forwarding path. This should be enough to nullify your patent
application.
That is not what patent is about. It specifies how path authentication
can be used in specific way after forwarding based on cryptographic data,
its not as wide as you think (altghough it does have several parts and what
you saw described in the draft is just one of the parts).
You are aware there is a bill pending that will require patent applicants
to
show proof of demonstration or implementation?
I was not aware of the bill. But lucky me, I've tested what I proposed.
Not really that hard - you add host name into signature and then pick
it up and use for SPF, read part 6 of the paper.
Anyway, as long as my system is based on a SMTP TMS generic framework, no
email patent has any legs in court.
IP: result := EPV(IP)
HELO: result := EPV-CDN(IP,HELO)
MAIL FROM: result := EPV-RPATH(IP,HELO,MFROM)
RCPT TO: result := EPV-FPATH(IP,HELO,MFROM, RCPT)
DATA: result := EPV-DATA(IP,HELO,MFROM, RCPT, DATA)
POSTSMTP: result := EPV-POST(IP,HELO,MFROM, RCPT,DATA)
That is fine, but I don't believe it will provide ability to reject based
on bad source. That is what I focused on when trying to solve forwarding
problem.
Our system already does all CHECKING after the Forwarding checking is done
and has been doing it atleast 2 years now. What is in "internals" is not
important, the end result is the same and a detailed patent MARKUS
analysis will tell you that:
821-A + 822-B + META-C(821-A,822-B) != PATENT META
So my advice?
If you want any hope of this to be considered, get off the IPR train.
That alone will nix all considerations in my book. You haven't even
proven it will work and I am not going to help you MAKE it work if it is
going to be a patented concept.
I don't see you screaming at Y! and MS like that.
My motivations are different then what you think, see above.
Also, if this a generic framework as I asked before, I believe you
borrowed
the "generic framework" ideas from my discussions here and in other places.
META-Signatures borrowed from x509 and couple other signature systems for its
framework design as well as borrowed from concepts proposed in ASRG.
The other things I worked on did not borrow anything from your work either
at least not anything that I'm actually apply patent for.
P.S. You should be happy I made disclosure like this directly in message
and in the document instead of like with IETF having to go through and
find it in separate documents.