At 10:03 PM 6/26/2003 -0600, Vernon Schryver wrote:
> From: "Peter Kay" <peter(_at_)titankey(_dot_)com>
>...
> A. there exists a plug-in infrastructure that can run on MUA or MTA
> (ISP).
Things that MTAs and MUAs can do differ radically.
If a user's ISP does not run a consent-system, then the user will probably
get a MUAs that does or a plugin for a MUAs that gives him that ability.
The implementation of consent on MUAs will obviously differ from
implementation on MTAs.
> B. each plug-in provides for some type of policy definition, related to
> the plugins purpose. This can range from filtering to CR to all the
> other methods mentioned below.
"Plug-in" worries me. At best it suggests an implementation mechanism
instead of a protocol notion. At worst it suggests an intolerable
security nightmare as is standard in commodity desktop software.
I think he picked a wrong term, we are seeking to create a common framework
for consent systems. Various pieces of this framework are implementation
specific and are done by MTAs and MUAs as they see fit. These various
implementation i.e. consent systems, all interoperate via standard
protocols such as CRI.
> C. each plug-in can be configured by a hierarchy. Starting w/ the ISP
> (for instance), then perhaps a domain-level admin (for corporate
> applications0 and then the end-user. We can decide on varying levels of
> defaults or override capability so that for example if an ISP whitelists
> a source, the end-user may have the option to blacklist it.
> ...
That needs to be made concrete in terms of protocols and mechanisms
so that it can be discussed by a technical group.
Correct, more discussion is needed. CRI would me an example of a protocol
that allows different consent systems to interoperate.
Yakov
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg