RE: [Asrg] CRI Header

Currently this is the 'requirement' - it is being slightly modified per Paul 
Judge's inputs.

2.9 Goal Oriented Solution

 The proposal SHOULD provide a carefully drafted scope of its
 goals and its effectiveness at addressing those goals. Systems
 SHOULD consider how they interoperate with other [anti-spam] systems.

-e

On Monday, June 09, 2003 12:22 PM, Yakov Shafranovich 
[SMTP:research@solidmatrix.com] wrote:
> At 05:09 PM 6/8/2003 -0400, Eric Dean wrote:
>
>
> >Maybe I'm a minimalist, but I'm not sure where 998 characters is a limit for
> >CRI.  Hell, I'm not even concerned about the 78 characters that are
> >"preferred".
> >
> >I would prefer not including hash cash, digital sigs, etc within a CRI
> >model.  I'd prefer to keep it simple.  that's not to say that these
> >additional capabilities are not warranted nor provide additional value.  In
> >fact, they may be of such value that they can stand alone.
>
> Should we be building in an extension mechanism that would allow for that?
> SMTP for example is a simple protocol, but has an extension mechanism which
> allows for a lot more complex stuff.
>
> >Regarding SMTP mods..I think we should reserve that concept and develop it
> >within a subsequent version...but rather focus and define what's currently
> >at hand.  There are a few dozen C/R system that could benefit from an
> >interworking model
>
> Agreed.
>
> > > Now that the issue on the RFC 2822 headers is settled, I would like to
> > > bring up the issue of MIME and SMTP for CRI. Like I pointed out
> > > before, in
> > > my opinion the CRI protocol should utilize both RFC 2822 and MIME
> > > headers,
> > > with optional SMTP negotiation. In certain instances, like Vernon stated,
> > > MIME headers would have to be used when large amounts of data
> > > (larger than
> > > the 998 character limit of RFC 2822 headers) need to be transferred.
> > > Examples would be C/R systems transferring digital certificate chains and
> > > replying with a single challenge/response message for multiple
> > > recipients.
> > > Additionally, SMTP CRI via some ESMTP extension would be useful
> > > in certain
> > > cases.
> > >
> > > Another very important point, is the need to define the CRI protocol as
> > > extensible. We need to provide space for implementors to add their own
> > > features such as hash cash, digital signatures, etc.
> > >
> > > Yakov
> > >
> > >
> > > At 10:47 AM 6/8/2003 -0400, Eric Dean wrote:
> > >
> > > >I'm pretty sure that it's clear we should move forward with
> > > proposing a new
> > > >RFC2822 header.  If a BOF wants to throw an X in front of it,
> > > then so be it.
> > > >I'll proceed br producing a draft with real 2822-type headers.
> > > >
> > > >However, if someone out there is interested, we could interoperate in
> > > >the
> > > >meantime using X or optional headers as well as with proposed
> > > 2822 headers
> > > >
> > > > > -----Original Message-----
> > > > > From: Eric D. Williams [mailto:eric@infobro.com]
> > > > > Sent: Saturday, June 07, 2003 11:11 PM
> > > > > To: 'Yakov Shafranovich'; 'Eric Dean'; asrg@ietf.org
> > > > > Subject: RE: [Asrg] CRI Header
> > > > >
> > > > >
> > > > > On Thursday, June 05, 2003 10:57 AM, Yakov Shafranovich
> > > > > [SMTP:research@solidmatrix.com] wrote:
> > > > > > At 11:15 PM 6/4/2003 -0400, Eric D. Williams wrote:
> > > > > >
> > > > > > >On Wednesday, June 04, 2003 3:54 PM, Eric Dean
> > > > > [SMTP:eric@purespeed.com]
> > > > > > >wrote:
> > > > > > >8<...>8
> > > > > > > > ok..optional headers or do we introduce a new one?  There
> > > > > isn't an RFC
> > > > > > > > 2822
> > > > > > > > registration process that I am aware of.
> > > > > > >
> > > > > > >IMHO the question at this stage is 'optional headers or the
> > > > > introduction
> > > > > > >of an
> > > > > > >new one?  Would a comparable RFC 2822 header field be as
> > > effective?'
> > > > > > >[..]
> > > > > >
> > > > > > Both an "X-CRI" and "CRI" headers should be defined. Until
> > > the standard
> > > > > > gets approved, the "X-" headers will be used, once the standard
> > > > > is approved
> > > > > > then both the "X-CRI" and "CRI" headers are used. This is
> > > similar to the
> > > > > > HTTP protocol where both "gzip" and "x-gzip" are used to
> > > indicate gzip
> > > > > > encoding (RFC 2616, section 3.5).
> > > > >
> > > > > I understand that, thanks.  But the issue I was trying to
> > > > > interpose is that
> > > > > perhaps the consideration of which would be more effective for
> > > > > the proposal is
> > > > > the type of question that should be asked at this state.
> > > > >
> > > > > -e
> > > > >
> > >
> > >
> >
> >_______________________________________________
> >Asrg mailing list
> >Asrg@ietf.org
> >https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg