On Sat, 18 Sep 2004, Meng Weng Wong wrote:
A patent application is not a patent; I understand that
nowadays applications are filed containing many claims that
the filer doesn't actually expect to be approved, but if
they are approved, bonus!
At the same time we also heard that only the most obvious claims are
rejected and that most are not and patent office is expecting that if
patent does not have a leg to stand on then it'll not be possible to
defend in court.
So let's look at which claims we
can realistically expect to survive into patent form, and do
our best to educate the patent office about the rest.
It appears patent office will ignore any attempts to contact them
regarding patent applications other then your own (i.e. you can contact
them in regards to somebody else patent application only as long as it
has anything to do with your own patent application and they conflict).
The ones that do make it into the patent may not turn out to be
an encumbrance after all, or if they are an encumbrance at
least we have a solid idea of how to route around them.
Hard to say...
On Sat, Sep 18, 2004 at 12:34:13PM +0100, Roy Badami wrote:
|
| I don't think that's true. The domain/IP verification schemes
| directly address forgery, in a way that CSV doesn't. Think about
| Sender ID as a tool for senders who (for whatever reason) want to be
| able to prevent others from sending forged mail claiming to be from
| them.
I agree that the anti-fraud aspects of SPF/Sender ID are
stronger than CSV, and should not be abandoned just yet.
Lets separate SPF from SenderID - they are in no way equivalent terms.
I see these terms as follows:
"SPF" is protocol in a way that it defines record format for representation
of policy record in dns that can whitelist or blacklist certain ip addresses
"SPF Classic" (now SPF Mail From) is using SPF protocol to protect RFC2821
Mail From (aka ReturhPath) identity of email system
SenderID is using SPF protocol to protect a validate new PRA identity based
on combination of RFC2822 headers From, Sender, Resent-From, Resent-Sender
CSV alone is not sufficient because it has a weaker
deployment driver than SPF / Sender ID. To wit:
Agreed. And CSV Authors themselve have proposed extensions to protect
RFC2821 Mail-From.
So it seems to me that the average domain owner has a more
compelling case to do SPF than CSV. I'm not saying nobody
will do CSV: I fully expect ESPs and ISPs to do CSV on their
MTAs, but you're not going to see uninterested parties
putting negative CSV assertions on all the other hostnames
that could be HELO'ed by MTAs. By contrast, I expect many
more people to put SPF records on their domains because the
benefits are more immediate and more apparent.
I do not think that we should do CSV + SPF (but its not a strong believe
as long as both are clearly standartized, its ok - I just think its easier
for implementation if ways to protect different identities is done in
simular way). I think that it would be better for overall standartization
process if we go with either CSV+MPR or Unified SPF (From + EHLO + PTR +
etc) with standard defined list of protected identities base on each method.
| As a tool for recipients, Sender ID and CSV both provide a hook on
| which to hang reputation and accreditation systems, and I'm agnostic
| as to which will work better in the real world, though my feeling is
| that they may in fact turn out to be complementary.
I agree that they will be complementary. In the same way
that restaurants offer a variety of eating options to
satisfy different needs, we should aim to offer a variety of
authentication options to accommodate the market better.
Lets not compare Apples to Oranges ....
There is a need to diverse options in the business market place, but there
is also reason why we have unified list of standard internet protocols and
why we have IETF for that matter.
As an example we have SMTP protocol that is defined and we dont have multiple
email systems (I note that in the IM world that is the case and its sad ...)
but we do have quite a number of diverse mail clients that users can use
and its very good that is so as it offers several interfaces to the system
so that people can choose one that best suites their enviroment and his/her
behavior in it. But in the end all this systems talk to each other no
matter how diverse.
I have been observing a pattern of fallacious debate which can perhaps
be called "winner takes all".
I do not believe that is the case. What is happening is that we're trying
to decide on best technical solution that can become standard and by
standard I mean something that everybody can implement.
It is not unusual for IETF to consider multiple technical approaches on
how to implement something, just recently on CRISP WG we had two ways
for new whois database system - FIRS based on LDAP and IRIS based on XML
over BEEP and both fully accomplished the requirements. In the LEMONADE
WG we had two proposals on how to implement remote email submission
that can include parts of existing email messages without downloading
them to MUA. DNS extensions WG considered two ways to implement IPv6 dns
records (A6 and AAAA), MULTI6 is considering several approaches on
how to implement multihoming with IPV6, etc. There are lots and lots
of workgroups that had before them several proposals and approachesto
solutiona and they had to choose one - that is part of standartization
process.
It is in fact those situations where standartization failed and where
opposting standards exist that created problems for deployement such is
the case of S/MIME and PGP and neither one has achieved wide deployment
as the programs supporting one often can not deal with the other type
of signature. I do not wish to be in the same situation with solutions
created by this WG and if we create something it must be something
that everone can deply and implement and that verification systems
are compatible with each other.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam Research Worksite:
http://www.elan.net/~william/asrg/