Subject: [Asrg] 0. General - Review of the CRI subgroup

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 08 Dec 2003 15:26:36 -0500

The CRI subgroup was created to work on the development of the CRI 
proposal to allow C/R systems to communicate. The group public homepage 
is at:

http://asrg.kavi.com/apps/group_public/workgroup.php?wg_abbrev=cri

The CRI proposal is located at:

http://www.ietf.org/internet-drafts/draft-irtf-asrg-cri-00.txt

We are currently reviewing this subgroup since it appears to lack enough 
interested participants. If you would like to participate in this 
subgroup, have comments on it, or any other questions, please let us 
know. If not enough interest is shown, we intend to shutdown this subgroup.

Sincerely,
Yakov Shafranovich
Co-Chair, ASRG
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Power tends to corrupt, and absolute power corrupts absolutely" (Lord 
Acton)
-------

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

---

From: "Eric Dean" <[email-masked]>
Date: Tue, 9 Dec 2003 17:02:14 -0500

Where we left off was in the process of building an interworking between
two or more interested parties.

I have a general concern around the amount of chatter in this RTF vs
actual work being performed.  It's quite frustrating to produce a
document for the benefit of the group to have it swept aside as
yesterday's news.

I would recommend that we focus on a particular area...maybe even one
document and produce something of value rather than reporting the
spam-evolution du jure.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Yakov Shafranovich
> Sent: Monday, December 08, 2003 3:27 PM
> To: ASRG
> Subject: [Asrg] 0. General - Review of the CRI subgroup
> 
> 

interested participants. If you would like to participate in this 
subgroup, have comments on it, or any other questions, please let us 
know. If not enough interest is shown, we intend to shutdown this
subgroup.

Sincerely,
Yakov Shafranovich
Co-Chair, ASRG
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com "Power
tends to corrupt, and absolute power corrupts absolutely" (Lord 
Acton)
-------

---

From: J C Lawrence <[email-masked]>
Date: Tue, 09 Dec 2003 18:55:41 -0500

On Tue, 9 Dec 2003 17:02:14 -0500 
Eric Dean <[email-masked]> wrote:

> Where we left off was in the process of building an interworking
> between two or more interested parties.

> document for the benefit of the group to have it swept aside as

I have been absent from this list for some months.  CRI appears to be
based on/inspired by a consent token protocol I noodled in May of this
year:

  http://article.gmane.org/gmane.ietf.asrg/3303

The current CRI protocol has moved away from binding tokens into email
addresses and message IDs apparently on the grounds of mail header
length limits.  However cursory scanning of the archives didn't reveal
identified cases where header length limits would be a problem, or a
clear assertion of why a consent token might need to be long/complex
enough to exceed RFC 2822 header lengths.  Was there a substantial
reason for moving to an abstract MIME type?

More significantly to my mind CRI clouds the distinction between consent
determination/maintenance and challenge/response (C/R is one method of
obtaining consent, but by no means need be the only one).  Was there a
substantial reason for narrowing the problem specification explicitly to
C/R from the more general question of consent definition and
manipulation?

I will have some free cycles in the new year.  If there is interest I'm
willing to move my prior noodles into draft form as well as to assist in
producing a TMDA patch which implements the protocol as a
sample/reference implementation (note that TMDA is a mail filter which
may be used for C/R and which implements a C/R system as a default
case).

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
[email-masked]               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

---

From: "Eric Dean" <[email-masked]>
Date: Wed, 10 Dec 2003 14:21:39 -0500

Yes, there is a general consensus that consent-based methods are
prefered; however, CRI is low hanging fruit and can be used to validate
some assumptions of consent-based.  In short, CRI is a subset of
consent-based...but a bit more widely deployed (though not much)

If you are willing to hack code..so am I.

> Behalf Of J C Lawrence
> Sent: Tuesday, December 09, 2003 6:56 PM
> To: Eric Dean
> Cc: 'Yakov Shafranovich'; 'ASRG'
> Subject: Re: [Asrg] 0. General - Review of the CRI subgroup 
> 
> 
> I have been absent from this list for some months.  CRI 
> appears to be based on/inspired by a consent token protocol I 
> noodled in May of this
> year:
>

---

From: J C Lawrence <[email-masked]>
Date: Mon, 15 Dec 2003 00:18:41 -0500

On Wed, 10 Dec 2003 14:21:39 -0500 
Eric Dean <[email-masked]> wrote:

Sorry for the delay.  End of year fanaticism is taking its toll.

> prefered; however, CRI is low hanging fruit and can be used to
> validate some assumptions of consent-based.  In short, CRI is a subset
> of consent-based...but a bit more widely deployed (though not much)

I see where you're heading and but partially agree.  Yes, CRI is low
hanging fruit and has a fair bit of public and developer attention
currently, however while a consent token protocol can use a CRI system
and does require similar acked communication exchanges to email-based
CRI, that really seems to be about the limit of the overlap.  Consent
protocols don't require CRI, don't need to bear much similarity at all
to CRI, and don't particularly solve similar problems at the human level
(CRI is supplicant based, consent is based on granted audience).

In an abstract sense I look at consent maintenance as a specialised form
of the problem of automatically maintaining current and correct email
addresses for correspondents as they move, change ISPs and jobs, etc.
The core for me is the machine assistance to the maintenance of a human
relationship.  How that relationship happened is rather beside the point
as long as the state machine has the proper transforms.

> If you are willing to hack code..so am I.

Excellent!

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 15 Dec 2003 20:22:05 -0500

>>If you are willing to hack code..so am I.

So perhaps the people that are interested in CRI can come up a set of 
concrete goals for the CRI subgroup?

Yakov

P.S. It has been expressed by several parties that C/R concept itself 
might be easier to deal with if it is done out of band - i.e. via an 
ESMTP extension or something similar, as opposed to inside email itself.

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"And this too shall come to pass"
-------