Re: Moving Forward

[jfcm <info@xxxxxxxx>]

Markus,
I can only repeat that I think the problem of this WG is a lack of
architectural vision which makes things exciting. This was the initial
debate and my call for ONES (open network extended services). At that
time I thought OPES were understood as partial ONES and I could not make
me understood. Now I understand that the way this WG perceives OPES makes
them fully complementary, the OPES being the peripherals of what I name
ONES, which are the final services managed by the call-out
servers.

The confusion we face (I feel) is another point of architecture. The
"S" in OPES is for "Services" and I feel we read it
as "System". 

I therefore propose the two layers diagram:

Service Intelligent Layer:
               
<---> OPES
ONES           
<---> OPES
               
<---> OPES  
--------------------------
System end to end Layer:
               
<---> shim
call-out server <---> shim
               
<---> shim

where final "OPES" applications (services) are provided
by the ONES located on call-out servers through local OPES (edge
services) via the shim pieces of software. This makes an exciting
architecture permitting to aggregate intelligence in the network, the way
people need it and do it, but in fully respecting the end to end
principle. This results from having actually _two_ end to end connections
in parallel, welded at the edge by the OPES: one is transport service,
one is intelligent service. This way there is no intelligence
"within" the network and no interference with the end to end
connectivity, dumb network, protocol on the wire principles. An image
would be a power plug, with two wires. Or the ADSL on the telephone
wire.

The shim (filter+OCP+Hopalong script) system which provides the OPES
service could then be located where we need it on the information path.
Including on/in/attached to the socket. We came from the
"proxy" image. But OPES are on the edge. There is a network
edge and a user edge. I submit that we should consider the
"shim" on either side of the OPES "virtual smart
plug" (male or female side): on the network or/and on the user side
(within/related to the socket).

I suppose that everything we did fits this scheme? But that it adds a
very exciting approach which is the very core of the development of what
the users strive for: an intelligent Internet. While keeping an unchanged
internet.

For example instead of just trying to see how to enhance SMTP in
competition with SMTP people, the target is to provide a smart mail
system in parallel (not over) of SMTP. This parallel intelligence notion
is the key. Up to now, the OSI model proposed a "layers"
pile  creating complex problems of interference/violation and rising
the question of "where is the intelligence layer in the end to end
connection". OPESes address the problem: the intelligence is neither
in nor on-top of the network layers, it is in parallel (plus probably in
what I could call an "intelligence control pannel" between
applications and the user where he can control both, an
"interapplication" layer encapsulating end to end transport and
intelligence: the OPES layer.

I submit that we could start from the SMTP cases to see better where
shims could be installed (within the whole mail application system) to
analyse what is shim, call-out, OPES and ONES oriented, how to manage it
through an interapplication layer (relating, for exemple, decisions
regarding mail routing sent by the ONES to the OPES, upon inputs of user
location/agend program). What is mail/smtp specific.

If my idea works we will have a very exciting architecture system. If it
does not work we could then close the WG?
jfc


At 02:49 10/08/2005, Markus Hofmann wrote:
> Folks,
>
> from the silence on the list and the lack of any response, I would
> conclude that there is *no* interest in moving forward with actually
> defining a OCP/SMTP profile.
>
> If this conclusion is wrong and there is interest in moving forward,
> please indicate your willingness to lead the protocol work and co-author
> a draft *now*.
>
> If there are no volunteers, I'll ask that the milestone and deliverable
> get removed from our charter. Given that we also don't make any progress
> on the rules language, I would then ask the AD/IESG to close the
> WG.
>
> Thanks,
>   Markus
>
>
> Markus Hofmann wrote:
> > Folks,
> > with the "SMTP Use Cases" draft bing submitted to IESG for
> > consideration as informal RFC, it's now time to move ahead to our next
> > milestone, which is
> >  "Initial document on OCP/SMTP profile for MTAs, including
> > mechanisms
> >  for tracing and bypass".
> > Does anyone believe the use cases draft is appealing enough so that it's
> > worthwhile to spend time and effort on developing a protocol that will
> > enable these use cases?
> > Who is volunteering to lead the protocol work and co-author a draft?
> > Thanks,
> >   Markus