ietf-openproxy
[Top] [All Lists]

RE: draft-ietf-opes-smtp-use-cases-01

2005-06-21 13:15:54

[sorry, this was intended for the list]

never mind. We can argue for years. You see OPES as a value added on protocol while I see them as extended services. The important point is that we may get out of all this with some system and go ahead. Both ways are parallel and have cons and pros in the current IETF context.
Its "Go" for me. Cheers.
jfc

On 12:01 21/06/2005, Martin Stecher said:
Hi,

> I do not recall all the examples and my computer lost me most
> of old mails.

There is an archive of the mailing list. See
http://www.imc.org/ietf-openproxy/index.html
The entries in the collected sample list
(http://www.martin-stecher.de/opes/smtpusecases.html)
link to the email in that archive in which they have been proposed.

> I may be wrong I do not see content translations, vote
> organisation, notes added to text (I am pushing right now
> hard so we are not blocked by WG-ltru language tagging which
> do not care about other applications - they name them troll
> :-) and to keep CRC (Community/Context Reference/Relational
> Centers) and other extended services and externet aspects in
> the IETF loop). Text related services must use language tags
> and the callout servers must rely on CRCs.

Content translation was already discussed in RFC3752.
Translation of the content is an application agnostic OPES
use case that always applies.
The introduction of this SMTP use cases draft refers to RFC3752
and says:
   This work focus on OPES for SMTP [8] use cases,
   whereby, additional use cases and enhancements to the types of OPES
   services defined in [2] are provided.

> [...]
>
> At 09:58 20/06/2005, Martin Stecher wrote:
> >(And btw, it does not need both ends to accept the selected
> routing of
> >an email)
>
> This is the security problem.

It is an SMTP issue. Routing selection is done by SMTP agents today
and not introduced by OPES. We are not here to fix SMTP.
The callout server may give the OPES processor some input for the
routing decision it has to do anyway. The general threats that OPES
introduces here are described in RFC3837.

Regards
Martin