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.
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.
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.
KH> We started down the "let's define spam" path on this list a week or
KH> so ago and then gave up. I think that was wise.
KH> How about another approach. Define what the problem with spam
KH> is--and then instead of focusing on defining the specifics of spam,
KH> focus on solutions to the problems that spam (and possibly other
KH> email) causes.
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.
Now for the bad news: The description needs to have enough technical
meat to permit us to pursue it with some change of success. For example,
saying something generic, like "prevent delivery of mail the recipient
does not want to get" is not going to get us anywhere productive.
---
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.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg