Re: Moving Forward
jfcm <[email protected]> Wed, 10 Aug 2005 10:04:04 +0200
| Newsgroups | gmane.ietf.opes |
|---|---|
| Message-ID | <[email protected]> |
--=====================_46311252==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
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
>
>
--=====================_46311252==.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<body>
Markus,<br>
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.<br><br>
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". <br><br>
I therefore propose the two layers diagram:<br><br>
<font face="Courier New, Courier">Service Intelligent Layer:<br>
<---> OPES<br>
ONES
<---> OPES<br>
<---> OPES <br>
--------------------------<br>
System end to end Layer:<br>
<---> shim<br>
call-out server <---> shim<br>
<---> shim<br><br>
</font>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.<br><br>
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).<br><br>
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.<br><br>
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.<br><br>
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.<br><br>
If my idea works we will have a very exciting architecture system. If it
does not work we could then close the WG?<br>
jfc<br><br>
<br>
At 02:49 10/08/2005, Markus Hofmann wrote:<br>
<blockquote type=cite class=cite cite="">Folks,<br><br>
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.<br><br>
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*.<br><br>
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.<br><br>
Thanks,<br>
Markus<br><br>
<br>
Markus Hofmann wrote:<br>
<blockquote type=cite class=cite cite="">Folks,<br>
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<br>
"Initial document on OCP/SMTP profile for MTAs, including
mechanisms<br>
for tracing and bypass".<br>
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?<br>
Who is volunteering to lead the protocol work and co-author a draft?<br>
Thanks,<br>
Markus</blockquote><br><br>
</blockquote></body>
</html>
--=====================_46311252==.ALT--