RE: [Asrg] CRI Header

On Tuesday, June 03, 2003 1:56 PM, Yakov Shafranovich 
[SMTP:research@solidmatrix.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@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg