I'm finding the large amount of discussion, albeit interesting,
also depressing, as it doesn't seem directed towards making
progress. So let me try to get back to the earlier question
concerning the charter:
1. On the use of "Consent-Based Communication"
The charter begins by arguing that spam is not well-defined,
and therefore moves to generalize the problem with consent-
based communications. Let me first observe that based
on the discussion here, the definition of consent and consent-
based communication isn't clear enough.
In engineering, when a problem seems intractable, it's certainly
a legitimate strategy to consider a different problem, as is
being done here. But then, unless the original problems falls
out (as is frequently but not always the case), we must compare
the original problem to the problem being solved.
In this case, my initial reaction was that consent-based
communication was sufficient but not necessary. That is,
such a system could significantly address the underlying
problem, but as defined, is more general than is necessary
(at least by any obvious necessity). But then, it occurred to
me that the approach is really just obscuring the original
problem.
My first take on "Consent Expression Component" was that it
was merely the mechanism to communicate my policy to the
software. We still need a way to identify policies - and
that means coming up with some sort of meaningful definitions
for spam. The trick is doing so, without forcing a single
definition of spam down everyone's throat.
2. A framework for classifying definitions of spam:
So let me propose a framework: Spam, as indicated in the
charter, is loosely defined as unwanted email. Within that
set, there are a number of very large categories. The
categories are not exclusive (they may overlap), nor do
they necessarily cover the entire space (some may slip through).
Some categories are defined intuitively, e.g. "unsolicited,
commercial, bulk". Others are defined formally, e.g. mail
for which the From field specifies a non-existent domain
(ignoring issues of DNS reliability and timing windows).
Sometimes there will be a relationship between an intuitive
definition and a formal one; the relationship may be perfect,
or it may have holes (false positives or negatives). The
closeness of a formal definition to an intuitive definition
is one particular measure of quality for that formal
definition.
At this point in time, arguing about the appropriateness of
any particular category (whether intuitive or formal) is
inappropriate. Rather, the point is to establish the structure
in which those categories can be documented and analyzed.
3. Legal issues
The statement about legal issues limits the investigation to
the extent that legal issues affect the technology. This needs
to be "and vice versa", i.e. should also consider the extent
to which the technology affects the legal issues. In particular,
it is a legitimate question to ask whether the technology can
and should play a role in aided the encorceability of legal
sanctions, e.g. can and should the technology make it easier to
find someone who violates an anti-spam law.
4. Social issues
The charter is silent on the effect on social (and political) issues.
The discussion here suggests that these are extremely important to
some number of people. I'm not convinced that adding such issues
to the charter would be a wise move, but in the interest of
completeness and fairness, I feel the need to point it out.
5. Premises or Constraints
The charter say very little about the premises or constraints
of what falls within its scope. The current set of discussions
indicates that many people are working under the premise that
existing (low-level) functionality must not be changed, or other
assumptions about approaches that would be out of bounds.
Since this is a research group, I believe it important to do
away with preconceived notions about limits. I also believe
it important to be explicit about this - precisely to avoid
ratholes. In particular, proposed solution should not be
rejected a priori solely on the basis of change of functionality,
but should be evaluated according to the same criteria mentioned
in the charter (usefulness, cost, effectivness, accuracy, etc.)
Furthermore, individual subsolutions should be evaluated in the
context of a complete solution strategy. In particular, if
one part of a solution breaks existing functionality, but that
purposes served by that functionality can be served by other,
new functionality, then rather than dismissing the subsolution,
the entire solution, including the replacement of existing
functionality should be evaluted. (Implicit in this is that
we also don't jump to a priori conclusions concerning the cost
of replacing functionality, but rather evaluate such costs
seriously.)
I'm sure some won't agree with the above specifics. Regardless
of the actual specifics chosen, I believe that such high-level
constraints should be clearly identfied early on and documented,
either in the charter or elsewhere.
Gary
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg