RE: [Asrg] CRI Header

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

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg