This message intends to address the issue raised concerning this statement:
'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.'
This is a SHOULD part of the broader requirement. Sorry if that was unclear.
I am getting back up to speed after a few days, only this message left
to go
;-).
-e
On Saturday, June 14, 2003 11:07 PM, Yakov Shafranovich
[SMTP:research(_at_)solidmatrix(_dot_)com] wrote:
> Can you be more specific as to which part of the CRI proposal you were
> referring to?
>
> At 10:58 PM 6/14/2003 -0400, Eric D. Williams wrote:
>
> >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(_at_)solidmatrix(_dot_)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(_at_)infobro(_dot_)com]
> > > > > > > Sent: Saturday, June 07, 2003 11:11 PM
> > > > > > > To: 'Yakov Shafranovich'; 'Eric Dean'; asrg(_at_)ietf(_dot_)org
> > > > > > > Subject: RE: [Asrg] CRI Header
> > > > > > >
> > > > > > >
> > > > > > > On Thursday, June 05, 2003 10:57 AM, Yakov Shafranovich
> > > > > > > [SMTP:research(_at_)solidmatrix(_dot_)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(_at_)purespeed(_dot_)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(_at_)ietf(_dot_)org
> > > >https://www1.ietf.org/mailman/listinfo/asrg