Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>:
I received some feedback from the FTC today. As it stands right now, the
FTC has only begun preliminary analysis of the bill. Since this
particular report on filtering has an 18 months deadline, work has not
begun on it yet. When the FTC begins working on this report, input from
the IETF and the ASRG will be solicited.
Good. Then the right time to standards-track a labeling RFC is *now*,
so we'll have it in hand with a decent amount of community review when
FTC comes knocking.
This goal is not exclusive of other RFCs or findings. The fact that
"input from the IETF and the ASRG will be solicited" means we MUST
have a constructive response in *addition* to whatever else we do, or
lose future influence on the interpretation and implementation of
CAN-SPAM.
I have a draft RFC, to which I've seen the following responses:
1. Several friendly corrections -- typo fixes, advice that I should
highlight the U.S. specificity of Can_SPAM, etc. I take these as
support.
2. A technical objection that the proposal needs to use a new header
rather than Keywords. Incorporated.
3. One misunderstanding about the scope of "commercial email" in CAN-SPAM
and my draft. This is the only objection that has produced even a threat
of a competing draft.
4. Two objections (one from John Levine, one from somebody else) that we
shouldn't have a labeling system because we should be doing something
else instead. As I've pointed out above, this is not responsive to the
political reality of CAN-SPAM.
I've been through the RFC mill before. This is a remarkably low level
or controversy, and very encouraging.
I'm volunteering to be the point guy on this. The issue interests me, and my
public fame might turn out to be a useful tool when it comes time to talk
the FTC and Congress out of peeing in the proposal so they'll like the
flavor better. We're at particular risk of that here because the issue
has little technical depth, increasing the risk that some bureacrat will
think he understands the background issues enough to "improve" an RFC. (The
most likely attempted "improvement" will be a more elaborate classification
system.)
Let me reiterate that I do not view this effort as competitive with
any of the other proposals on the table (LMAP, callback, pull, MTA
labeling, whatever) but as complementary with them.
Those of you with interest in this issue, please work with me to
improve the draft.
What is the next step? If I'm reading RFC2026 correctly, it would be
publishing my proposal as an Internet-Draft with a view to having it
accepted as a Proposed Standard.
Is this a candidate BCP or TS? I can see arguments in both directions.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg