James M. Polk [EMAIL PROTECTED] writes:
At 04:48 PM 10/29/2007, Simon Josefsson wrote:
Eric Burger [EMAIL PROTECTED] writes:
One interesting side effect of the existence of an open source
implementation of a protocol is monoculture. We ran into a problem in
ifax year ago when it turned
That was a waste of your time and money. Publication of those
inventions by you, at zero cost to you and others, would have
been sufficient to prevent someone else from trying to patent
them. Next time, get good advice from a patent lawyer on how
to achieve your goals without paying for a
[I'm changing the subject and cutting off the references list as we seem
to have changed topic.]
Simon,
DS designates a mature standard. If you read the requirements in RFC
2026 for a mature standard it is clear that few of the modern IETF
protocols live up to that standard -- you need to
On Tue Oct 30 10:18:08 2007, Eliot Lear wrote:
I think we can all agree that the calendaring standard is mature.
We
are in the process of doing what I would consider to be a relatively
minor update to it, and yet it is only PS. IMAPv4 is only PS and
yet
has MASSIVE deployment. LDAP is
More to the point, patent law is one of the only two areas of law where you
are guilty until you can prove yourself innocent. The other is tax law.
Yes, I could have simply published the work. That establishes prior art.
However, let us consider this very real (I have experienced it) scenario.
I specifically applied for patents underlying the technology behind
RFC 4722/RFC 5022 and RFC 4730 specifically to prevent third parties,
who are not part of the IETF process, from extracting royalties from
someone who implements MSCML or KPML.
That was a waste of your time and money.
Larry
Sorry that I answered before seeing that others
had already said the same thing.
However, even after reading your subsequent email,
I am unconvinced. Requesting a re-examination
is a lengthy process, and if unsuccessful further
strengthens the party holding the patent
(as it has gone
I've suggested before that the advancement of a specification
is a highly overloaded action - it implies that the IETF
thinks it's a good idea, it implies that the specification is
sound, it implies it's well deployed.
Does the IETF have a way to communicate that a specification is
a good
--On 29. oktober 2007 17:53 -0700 Lawrence Rosen [EMAIL PROTECTED]
wrote:
The notion that each IETF working group has to approach patent issues on
its own, without help, is silly.
It's also a straw man.
RFC 3669. You may argue that we can do better, but the argument that there
is no
On Oct 27, 2007, at 2:52 PM, Brian E Carpenter wrote:
On 2007-10-28 06:36, Andrew Newton wrote:
On Oct 27, 2007, at 11:00 AM, David Morris wrote:
Well for starters, the drive-by hummers have to sit through the
session
and be present for the discussion (note I intentionally did not say
Eric Burger wrote:
5. I am now facing US$ 250,000 minimum, US$ 1,000,000 typical, in legal fees
to invalidate the patent issued in step 3.
From what I've been told, $1M is more like the entry fee for this contest, if
the patent holder has any tenacity at all. And if they do, it gets a lot
Hi Eric,
I generally agree, that patents are not *necessarily* evil ... just that
they can be, so need to err on the side of caution.
Phil Zimmerman has applied for patents in ZRTP, specifically to ensure
that all implementations fully conform with the specification. Cost to
license for a
At 04:24 AM 10/30/2007, Simon Josefsson wrote:
I admit now
s/now/not
all PSs have IPR attached, but this is almost certainly
intended to kill any IPR from achieving DS. Is that what is intended
here?
I don't believe that was the intention, but that's a question for Brian.
I disagree
At 04:24 AM 10/30/2007, Simon Josefsson wrote:
At 04:48 PM 10/29/2007, Simon Josefsson wrote:
Eric Burger [EMAIL PROTECTED] writes:
One interesting side effect of the existence of an open source
implementation of a protocol is monoculture. We ran into a problem in
ifax year ago when it
Dave Cridland wrote:
On Tue Oct 30 10:18:08 2007, Eliot Lear wrote:
What benefit does it bring to anyone to advance a standard to DS? AND
it's a whole lot of work.
But it does do some good to review past specifications and note if
they're still ok, it does do some good to note that
At 05:18 AM 10/30/2007, Eliot Lear wrote:
[I'm changing the subject and cutting off the references list as we seem
to have changed topic.]
Simon,
DS designates a mature standard. If you read the requirements in RFC
2026 for a mature standard it is clear that few of the modern IETF
On 2007-10-30 23:18, Eliot Lear wrote:
[I'm changing the subject and cutting off the references list as we seem
to have changed topic.]
Simon,
DS designates a mature standard. If you read the requirements in RFC
2026 for a mature standard it is clear that few of the modern IETF
protocols
[By the way, when I find myself in a WG meeting I'm not prepared
for, I often have my head buried in the drafts being discussed,
so as to be able to understand the issues. Don't assume that a head
buried in a laptop is always doing email.]
Has there been an assumption that these
[I'm changing the subject and cutting off the references list as we seem
to have changed topic.]
Simon,
DS designates a mature standard. If you read the requirements in RFC
2026 for a mature standard it is clear that few of the modern IETF
protocols live up to that standard -- you need
I agree, but only partly.
A second pass on the documents does have a beneficial effect. This is
particularly the case for older 'standards' where the documents simply don't
match current requirements (no security, iana considerations for a start) and
are often missing key folklore essential
Phil's strategy here is not without issues. This was raised during the W3C
discussion when IBM pointed out at length that a license fee can be
considerably less of an inconvenience than certain Zero fee licenses.
So for example a requirement that you can only implement a protocol using Java
The IESG has approved the following document:
- 'MIB for the UDP-Lite protocol '
draft-ietf-tsvwg-udplite-mib-03.txt as a Proposed Standard
This document is the product of the Transport Area Working Group.
The IESG contact persons are Magnus Westerlund and Lars Eggert.
A URL of this
The IESG has approved the following document:
- 'Interactive Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal for Offer/Answer Protocols '
draft-ietf-mmusic-ice-19.txt as a Proposed Standard
This document is the product of the Multiparty
23 matches
Mail list logo
