At 7:17 -0800 3/30/03, Dave Crocker wrote:
>>This is a technical forum. Please list any of the technical mechanisms
...
JY> These sorts of minute-by-minute challenges are unlikely to lead
to anything
JY> useful. Why can't you just say that if someone wants to promote the idea
JY> of a consent mechanism, that they should announce a research thread and
JY> pursue it.
There are approximately and infinite number of ideas that can be
suggested. We have limited resources and only a few idea are likely to
be productive.
If an idea has not had enough thought behind it, to strongly suggest
that pursuing
the idea will be productive, then it should not be pursued.
I don't think i can agree with that. I'd rather see some evidence
first than trying
to pass judgement about someone's idea. If there's an idea here, maybe the best
thing is to reply with suggestions. If it's been proposed before,
then don't debate
it, send the poster back to do some reading and if you have pointers,
offer them.
The issue at hand in this thread was something about "consent" and
frankly, there seems
to be no consensus here. If someone(s) believe that "consent" can be
codified and made to
work, then send them off to work on it for awhile and then come back
to tell us what
they've learned.
When someone suggests that an idea be pursued, they have a
responsibility to offer its technical basis.
Otherwise, it is just a random thought with almost no chance of being
useful.
These "minute-by-minute challenges" are being offered in response to
minute-by-minute "requirements". This is a difficult topic and
productive work on it requires respecting its difficulty.
These minute-by-minute challenges are serving only to increase the rate of
minute-by-minute responses. I'll say it again... If someone thinks they've got
a good solution, they need to be sent off to work on it.
An idea that sounds good must also have enough technical basis
accompanying it to demonstrate that it might be productive for this
group to pursue.
And where will that technical basis come from? From going off to work on it
and coming back with results.
I think that is a fine idea. I don't care whether we define spam or
another term, but we MUST have an objective, technical definition of the
problem we are working on. Agreeing on an objective, technical
description of the problem's EFFECT sounds like an excellent approach.
Otherwise each of us is trying to solve a different problem.
I think it will be more useful to define some problems. The problem is not
"spam exists"... the problem seems to be something about too many undesired
messages hitting ISPs and their customers, which messages can't be made to
stop using current art, or something. I don't think you're going to define
much with specificity... each of the possible "solutions" approaches a
subset of what we recognize as the "spam problem" - let the solution
writer state what problem he is trying to solve.
Hmmmm. It occurs to me that I keep saying that this problem requires
multiple components to the "solution". No one thing is going to fix the
problem.
Perhaps we need a cascading sequence of definitions, starting from the
most simple and mechanical, up to one that is quite general. The simple
one permits a simple mechanism that will be easy to build, will work
reliably, but eliminate only a percentage of the problem mail. Each
definition becomes more general, and leads to a mechanism that is more
general, and less reliable, but has some utility.
I think that will lead to a cascade of arguments about definitions.
If there will be many solutions to many problems, they probably will not fit
neatly together.
Use the list to hook up people who believe in/against some approach, hook them
up so they can work together, send them off to work on it and invite
them to come
back when there's something defensible to show. Only then will it be
useful to look
at what they've got and pass judgement on whether it's useful
generally, and whether
it's compatible with other bits of solution.
I haven't read even one of the multi-page back-of-envelope
"solutions" that have
been posted here.
May I also suggest that a proper use for this group would be to define the
features and data that must be present for any proposed solution or research to
be taken seriously?
eg: - what must change for this to work
- what is the impact on those who don't have it
- in/compatibility with existing infrastructure
- results of test against some standard corpus
- analysis of adaptations and workarounds
- simulation where appropriate
or just debate what spam means til yer pink and gelatinous in the face.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg