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

[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