Re: Moving Forward

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