RE: [Asrg] CRI Header

[Yakov Shafranovich <[e-mail]>]

So I am assuming that you will be adding extensibility requirements as part 
of the requirements draft you are working on?

At 11:48 PM 6/14/2003 -0400, Eric D. Williams wrote:

>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:[e-mail]] 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:[e-mail]] 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:[e-mail]]
> > > > > > > > Sent: Saturday, June 07, 2003 11:11 PM
> > > > > > > > To: 'Yakov Shafranovich'; 'Eric Dean'; [e-mail]
> > > > > > > > Subject: RE: [Asrg] CRI Header
> > > > > > > >
> > > > > > > >
> > > > > > > > On Thursday, June 05, 2003 10:57 AM, Yakov Shafranovich
> > > > > > > > [SMTP:[e-mail]] wrote:
> > > > > > > > > At 11:15 PM 6/4/2003 -0400, Eric D. Williams wrote:
> > > > > > > > >
> > > > > > > > > >On Wednesday, June 04, 2003 3:54 PM, Eric Dean
> > > > > > > > [SMTP:[e-mail]]
> > > > > > > > > >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
> > > > >[e-mail]
> > > > >https://www1.ietf.org/mailman/listinfo/asrg

_______________________________________________
Asrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg