On Tuesday, June 03, 2003 1:56 PM, Yakov Shafranovich
[SMTP:research(_at_)solidmatrix(_dot_)com] wrote:
8<...>8
I thought you guys were clever to use MIME for more than one reason.
Pushing a new official RFC 2822 header (other than an ad hoc X-whatever)
through the IETF would take a year or more and you might fail. That
you are sure challenge/response systems will be effective against spam
will be a weak response to Last Call criticisms. However, I've the
impression that MIME headers don't have that bureuacratic problem to
the same degree. That should be checked.
According to section 2.1.1 of RFC 2048, there is plenty of bureaucratic
problems involved. I am assuming that we would want to register this MIME
type under the IETF tree, if so the following from RFC 2048 applies:
"The IETF tree is intended for types of general interest to the Internet
Community. Registration in the IETF tree requires approval by the IESG and
publication of the media type registration as some form of RFC."
The MIME type would have to go through the standards process anyway.
Additionally, all MIME types of type "message" which I am assuming will be
used for CRI, have been registered based on RFCs (take a look at
http://www.iana.org/assignments/media-types/message/).
The rigor of the Last Call and criticisms of a Standards Track RFC should not
IMHO be a limiting factor on the work of this group. The point would be
whether a MIME type would be an appropriate methodology for addressing the
'spam' problem. This is not an IETF working group (as many have said).
As a researchy group perhaps the focus would be better placed on how such a
MIME type would work and/or the benefits and constraints of using either a MIME
type or 2822 ad hoc private header field (X-). How such a content type would
work is also a valid research area in addition to what effects such a construct
would have on the 'spam' problem.
IMHO I would not focus on what the IETF process is at this stage OR if it is a
must to you, I would suggest including it as a constraint or assumption that is
addressed by the documentation of proposed method.
-e
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg