Subject: Re: Moving Forward

From: Markus Hofmann <[email-masked]>
Date: Tue, 09 Aug 2005 20:49:41 -0400

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

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Tue, 9 Aug 2005 22:58:12 -0600

With some trepidation, I offer

http://www.purplestreak.com/ietf-opes/draft-ietf-opes-rules-language-hopalong-00.txt

It is incomplete in several aspects, particularly the detailed grammar,
but I think that it gets at the heart of defining a stream processing
language for OPES.  I had intended to use the Sieve grammar, but
in the time I had for this, I couldn't decide if it is worth the
trouble of using the funky notation.

Comments are, of course, welcome, even more so than no comments.

Hilarie

---

From: jfcm <[email-masked]>
Date: Wed, 10 Aug 2005 10:04:04 +0200

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:
>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,
>>as informal RFC, it's now time to move ahead to our next milestone, which is

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 12 Aug 2005 15:28:09 -0600

On Tue, 2005-08-09 at 22:58 -0600, The Purple Streak, Hilarie Orman
wrote:

> 1. Applicable to partial messages (packet-by-packet)

I would remove the references to "packets" from the draft. None of the
protocols we think of dealing with (HTTP, OCP, SMTP, IMAP, RTSP) have a
notion of a packet.

Support for partial messages or, more precisely, partial message
payloads (potentially large bodies and such) is a must, of course.
Beyond that, incomplete "parts" should be invisible to the rules
language. The language does not need to deal with a truncated HTTP
header field or a partially received IPv6 address, for example. 

If the protocol defines an "element" or "part", the rules should be able
to access that part (usually via protocol-specific modules). Splitting
e;ementary parts into smaller chunks should be out of scope.

Note that if your description promises support for application protocol
elements (headers, bodies, etc.) than it would be possible to support
packets as well, but only for protocols that deal with packets...

Another unrelated comment is that we should not assume that a message is
always headers+body. Even HTTP messages are not like that because they
may have trailers. I think a couple of places in the draft may imply
otherwise.

If there is an error but there are no matching onError rules, what
happens?

Is there arithmetic support? For example, can I count the number of
certain headers in the message?

Please add at least one non-trivial/semi-complete realistic example.

Thank you,

Alex.