Subject: Re: [arch-d] Defining terms

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Apr 2006 15:04:09 +0200

(catching up)

John Leslie wrote:
> Scott W Brim <[email-masked]> wrote:
> 
>>On Mon, Mar 06, 2006 03:02:24PM -0800, Fred Baker allegedly wrote:
>>
>>
>>>I would therefore define a "session" as the shared state in the end  
>>>systems and in the network, whatever it may be, which directly or  
>>>indirectly reflects the state of two or more communicating  
>>>applications. In Flow RED (http://www.icir.org/floyd/red.html#flow),  
>>>this would include information stored in network nodes, and it  
>>>generally includes keys associated with security associations,  
>>>sequence numbers etc in TCP and SCTP, and the various addresses that  
>>>are used by endpoints in a multihomed route.
>>
>>Elsewhere people have come up with the concept that a "session" is a
>>relationship -- not a pipe, not a flow of packets -- created to align
>>state information.  To do so it may use one or multiple communication
>>events.  A successful session could be as simple as "are you there?"
>>with a response.
> 
> 
>    I see a benefit to thinking of "session" as a relationship between
> endpoints. I'm not quite sure either Fred or Scott have stated this
> distinctly enough.

I think this is spot on, and that there is a direct implication:

Whatever "session" is, it's not a layer. Looking for it in the traditional
layered stack is a wild goose chase.

     Brian

> 
>    Fred is talking "shared state" which, I suppose, is correct; but it
> tends to direct our attention to details of connection(s) which I think
> deserve to be considered a different layer. IMHO, "session" may or
> may not imply an ordering in information transmitted over different
> connections.
> 
>    Scott talks of a "session" being "created to align state information."
> I do not see that either as the "purpose" of a "session" or even a
> necessary function of a "session". IMHO, a "session" should identify
> endpoints which are processes invoked by users without regard to the
> path over which information will flow between them.
> 
>    (Whether or not a "session" implies ordering of data communicated
> might well be implementation-dependent.)
> 
> 
>>Neither is a session the state information itself.  I think these
>>terms will be more useful in the future if you distinguish the
>>relationship between the endpoints -- the "session" -- from the
>>"session state" which reflects the relationship in the participants
>>and intermediate nodes.
> 
> 
>    I agree with Scott.
> 
> 
>>How is a session different from a connection?  Just barely.
> 
> 
>    I think we can draw a fairly clear distinction, actually.
> 
>    A "connection" is something maintained in a fully automated manner,
> without messy interactions. Our network must find a way to route packets
> from one end to the other. Thus, the endpoints of a connection must be
> machine-comprehensible addresses, most often globally unique.
> 
>    A "session" is something created in response to human action. In
> all likelihood, it depends upon rather messy DNS processes to resolve
> to IP addresses which routers can use. If conditions change so that
> those IP addresses no longer serve the necessary function, the human(s)
> creating the "session" would generally prefer that some further DNS
> magic makes the change transparent.
> 
> 
>> A TCP "connection" can be used by HTTP for one exchange, then allowed
>>to lie fallow, then used for a different one.
> 
> 
>    Agreed.
> 
> 
>>That's one "flow" from the point of view of the network but multiple
>>communications events from the point of view of the applications.
> 
> 
>    True, but in practice all the communications events are likely to
> represent the same "session".
> 
> 
>>One possible difference between session and connection might be that
>>in a connection the participating endpoints are the same for all
>>communication flows, while in a "session" involving multiple
>>communication events, different parties could be involved in different
>>ones.
> 
> 
>    I think I've missed Scott's point here.
> 
>    "Participating endpoints" could mean a number of things. IMHO, we
> can correctly talk of "participating endpoints" for both "connections"
> and "sessions", and mean quite different things.
> 
> 
>>You don't buy it? In that case, really, the only difference I know of
>>is that "connection" is used for lower layers, L4 and below, while
>>"session" is used for L5 and above.
> 
> 
>    Alas! We can't accept that kind of definition. ;^(
> 
> --
> John Leslie <[email-masked]>
> 
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/architecture-discuss
> 

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 11 Apr 2006 00:29:06 +0200

>layered stack is a wild goose chase.

Can we agree it is a one shot implication of all of them. Supported 
by a connexion (low layers). Part of a relation (usage layers above OSI)?
jfc

---

From: John Day <[email-masked]>
Date: Tue, 11 Apr 2006 09:35:02 -0400

>by a connexion (low layers). Part of a relation (usage layers above 

No, there is no such thing as a Session Layer.  This is one of the 
things OSI *did* figure out and fairly early.  Interestingly enough, 
they might not have realized it if the CCITT had not stolen what was 
called the Session Layer for Videotext.

What there is needed is a common application connection establishment 
module that carries the application naming information (called ACSE) 
and in the OSI case a placeholder for a simple authentication 
mechanism (there is also a common connectionless unit data protocol). 
Application protocols are made up of one or more modules that define 
the data transfer phase.

What came out of the Session Layer being stolen was, it made them 
look hard at the boundary between what was "communications" and what 
wasn't.  (Other ISO committees standardize other things, so to some 
degree there was a question as to where communications stopped and 
applications started. A bit of a turf battle.)  This was an intense 
and often esoteric debate about the nature of applications and what 
was inside and outside "the OSI environment."  (Amusingly, the only 
short name we had for the discussion couldn't be used in any official 
minutes.  Everyone referred to it as the "balls in/balls out 
problem.")  When I heard what the solution was: the balls were on the 
line, I thought it was a typical standards committee wimp out, but 
turns out to be the right answer.

They distinguished the Application-Entity (AE) as being the comm part 
of the application process (AP).  An AP has one or more AEs (and 
potentially one or more instances of each).  So for example, a 
reservation application, the AP, might have an AE for HTTP for the 
interface to the user and an AE for a remote database protocol to the 
reservation database (and multiple instances of both for multiple 
users and different databases).  The AP is what glues the use of the 
two AEs together and anything else specific to the application.

This is a distinction we didn't see in the early Net until the web 
came along, because all of the applications we had done up to then 
turn out to be special cases, where the AE IS the AP, i.e. there is 
little or no "AP functionality" and there was generally one per 
system. For example, there is very little of Telnet or FTP that isn't 
the protocol, just reading and writing the file in the FTP case. 
With one per system,  addressing the protocol *was* addressing the 
application.  It is only with the web where getting to HTTP, i.e. the 
AE, isn't the important thing, it is getting to cnn.com, i.e. the AP, 
that is the thing being addressed.  There are lots of applications 
all different that must be addressed and they all use the same 
protocol.

This turns out to be a very simple and powerful model.

As for the Session Layer. By 1983, OSI had figured out the upper 3 
layers were a single layer and had adjusted the protocol specs so 
that the savvy implementor would see that he shouldn't build 3 
separate layers.  Which is how some of us build it.  (The bellheads 
in OSI insisted on keeping the distinction because they had used it 
for Videotext and later had based X.400 directly on the Session Layer 
rather than use Presentation and ACSE.

It also turns out that the functions that were put in the Session 
Layer, all of those "dialog control functions," really can only be 
used there by the simplest applications.  Once you go to the least 
bit of complication, like mail or transaction processing, you find 
that there are problems having these functions below the application 
and not common modules in the application protocol. (In essence, they 
aren't "reentrant" and it adds unnecessary complexity to separate 
them and make them "reentrant.")

So, no there is no Session or Presentation Layer, only an application 
layer and the application layer consists of applications consisting 
of one or more AEs.

The reason I say it was fortunate that CCITT stole the Session Layer 
is that had they not, OSI probably would have made the Session 
*Layer* the common application establishment mechanism and tried to 
put common functions in there and that would have turned out to be 
the wrong structure. But instead, it was done as part of the 
application process which is much more flexible, simpler and more 
powerful.

Take care,
John

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 12 Apr 2006 15:32:55 +0200

>>by a connexion (low layers). Part of a relation (usage layers above OSI)?

Hi! John,
I am afraid there is a confusion. I did not refer to a "session 
layer", but to a "session". A complete session uses all the layers, 
at least one time.

>What there is needed is a common application connection 
>establishment module that carries the application naming information 
>(called ACSE) and in the OSI case a placeholder for a simple 
>authentication mechanism (there is also a common connectionless unit 
>data protocol). Application protocols are made up of one or more 
>modules that define the data transfer phase.
>
>short name we had for the discussion couldn't be used in any 
>official minutes.  Everyone referred to it as the "balls in/balls 
>out problem.")  When I heard what the solution was: the balls were 
>on the line, I thought it was a typical standards committee wimp 
>out, but turns out to be the right answer.

Correct. But they did not consider all what can be on the line. Or 
let put it differently where the lines end and how. They were one 
ball guys, not usual two balls guys (value added and extended 
services). They considered the envelope of the carried objects, not 
the content.

>They distinguished the Application-Entity (AE) as being the comm 
>part of the application process (AP).  An AP has one or more AEs 
>(and potentially one or more instances of each).  So for example, a 
>interface to the user and an AE for a remote database protocol to 
>the reservation database (and multiple instances of both for 
>multiple users and different databases).  The AP is what glues the 
>use of the two AEs together and anything else specific to the application.

This is a one layer short (8th interapplication layer) approach. They 
failed to see that the network may deliver the users different 
contents due to elements external to the network ends but internal to 
the users ends. Is the network what the engneers build or what the users use?

>system. For example, there is very little of Telnet or FTP that 
>isn't the protocol, just reading and writing the file in the FTP 
>case. With one per system,  addressing the protocol *was* addressing 
>the application.  It is only with the web where getting to HTTP, 
>i.e. the AE, isn't the important thing, it is getting to cnn.com, 
>i.e. the AP, that is the thing being addressed.  There are lots of 
>applications all different that must be addressed and they all use 
>the same protocol.
>
>for Videotext and later had based X.400 directly on the Session 
>Layer rather than use Presentation and ACSE.
>
>and not common modules in the application protocol. (In essence, 
>they aren't "reentrant" and it adds unnecessary complexity to 
>separate them and make them "reentrant.")
>
>So, no there is no Session or Presentation Layer, only an 
>application layer and the application layer consists of applications 
>consisting of one or more AEs.
>
>application process which is much more flexible, simpler and more powerful.

This explains why OPES (which try to embody the interapplication 
layer, below the user application and above the network application 
layers) is a so confused WG. Why it was not able to accommodate the 
ONES concept (Open Network Extended Services). OSI is about value 
added services delivering, with various contextual modifications the 
"A" which was sent. Usage Networking is about delivering the "B" the 
user wanted in sending an "A", because an online extended service he 
chose obeyed the "A" to deliver "B". This is only feasible if the 
network is understood as a network operating system and if the 
network processing power is not on the "network end to network end", 
but on a ONES welded on the "user end to the user end".

Not supporting this in ISO and TCP/IP (Tymnet fully supported it - my 
Extended Network Services Department was to build on it) is why the 
Internet can only be internationalized and not multilingualised. Why 
I cannot send in French, and you receive in English (except possibly 
under HTTP. Cf. RFC 3835, 4037, 4237). Why there are chapel disputes 
over the single authoritative root - leading to balkanization. Why 
the IAB cannot accept that when I click on the link you propose, I go 
to the page I want (otherwise hyperlinks are spam). The IETF tyranny 
comes from this necessary but uncompleted analysis.

Take care.
jfc

---

From: John Day <[email-masked]>
Date: Wed, 12 Apr 2006 11:08:27 -0400

>>>Can we agree it is a one shot implication of all of them. 
>>>Supported by a connexion (low layers). Part of a relation (usage 
>>>layers above OSI)?
>>>jfc
>
>Hi! John,

Okay.  Perhaps.

>>things OSI *did* figure out and fairly early.  Interestingly 
>>enough, they might not have realized it if the CCITT had not stolen 
>>what was called the Session Layer for Videotext.
>>
>>establishment module that carries the application naming 
>>information (called ACSE) and in the OSI case a placeholder for a 
>>simple authentication mechanism (there is also a common 
>>connectionless unit data protocol). Application protocols are made 
>>up of one or more modules that define the data transfer phase.
>>
>>look hard at the boundary between what was "communications" and 
>>what wasn't.  (Other ISO committees standardize other things, so to 
>>some degree there was a question as to where communications stopped 
>>and applications started. A bit of a turf battle.)  This was an 
>>intense and often esoteric debate about the nature of applications 
>>and what was inside and outside "the OSI environment."  (Amusingly, 
>>the only short name we had for the discussion couldn't be used in 
>>any official minutes.  Everyone referred to it as the "balls 
>>in/balls out problem.")  When I heard what the solution was: the 
>>balls were on the line, I thought it was a typical standards 
>>committee wimp out, but turns out to be the right answer.
>

Well, yes and no.  First of all, the content was to some extent 
viewed as the purview of the AP, not the AE and hence outside the OSI 
environment and the domain of other standards.  So in that sense you 
are correct.  They did not consider it.

On the other hand, ACSE was defined to be used recursively so that 
distributed applications could be built on top of distributed 
applications.  In fact this was shown to be quite powerful.

>This is a one layer short (8th interapplication layer) approach. 
>They failed to see that the network may deliver the users different 
>contents due to elements external to the network ends but internal 
>to the users ends. Is the network what the engneers build or what 
>the users use?

Not sure what you are describing here.  But as I indicated above I 
think the recursive use of ACSE (which included negotiating the 
syntax of encapsulated applications) may have addressed this.

>>case. With one per system,  addressing the protocol *was* 
>>addressing the application.  It is only with the web where getting 
>>to HTTP, i.e. the AE, isn't the important thing, it is getting to 
>>cnn.com, i.e. the AP, that is the thing being addressed.  There are 
>>lots of applications all different that must be addressed and they 
>>all use the same protocol.
>>
>>that there are problems having these functions below the 
>>application and not common modules in the application protocol. (In 
>>essence, they aren't "reentrant" and it adds unnecessary complexity 
>>to separate them and make them "reentrant.")
>>
>>application layer and the application layer consists of 
>>applications consisting of one or more AEs.
>>
>>The reason I say it was fortunate that CCITT stole the Session 
>>Layer is that had they not, OSI probably would have made the 
>>Session *Layer* the common application establishment mechanism and 
>>tried to put common functions in there and that would have turned 
>>out to be the wrong structure. But instead, it was done as part of 
>>the application process which is much more flexible, simpler and 
>>more powerful.
>

You are going to have to explain further because I was not able to 
make any sense of this paragraph.  Sorry.

>Not supporting this in ISO and TCP/IP (Tymnet fully supported it - 
>my Extended Network Services Department was to build on it) is why 
>the Internet can only be internationalized and not multilingualised. 
>Why I cannot send in French, and you receive in English (except 
>possibly under HTTP. Cf. RFC 3835, 4037, 4237). Why there are chapel 
>disputes over the single authoritative root - leading to 
>balkanization. Why the IAB cannot accept that when I click on the 
>link you propose, I go to the page I want (otherwise hyperlinks are 
>spam). The IETF tyranny comes from this necessary but uncompleted 
>analysis.

Again, I think you are going to have to try again.

Take care,
John

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Wed, 12 Apr 2006 18:33:34 +0200

I explain again as a quick desc, rather than responding points. I 
observe three levels of networking services.

- basic services: sender sends A in a square and receiver 
interactively receives an A in a square. This is what 
telecommunications are about.

- value-added services: sender sends an A in a square and receiver 
receives (interactively or not) an A in a circle. The envelope has 
been serviced. This is datacommunications.

- extended services. sender sends an A for the network to deliver a B 
resulting from an internal or external intelligence, the receiver may 
turn into a C calling on its own Intelligent Services Provider 
extended services.

The terminology problem is that layer 7 is named applications and 
users may run applications, even networked applications of 
applications, etc. But there are not the same kind of applications. 
Some are to provide interoperability, some to provide 
interintelligibility, other to obtain a result. E-Mail is a layer 7 
application. DNS is too. My email sorting plug-in is not.

Extended services are no layer 7. There are in a layer OSI does not 
consider. That layer is the network OS layer. Between the network 
applications and the user applications. The ENS model we devised 
embeds communication models into an extended understanding of 
networking services. In the OSI case, it uses three layers:

- layer 7 OSI  : applications - interoperability
- layer 8 ENS : interapplications - interintelligibility
- layer 9 ENS : user agent. The applications you refer to as user 
applications are located here.

The user (layer 10) sees the network through his user agent (layer 
9). The network he sees is the layer 8 out-put. The role of layer 8 
is to weld all the layer 7 network applications it may relate with 
(they can be different links under different technologies, networking 
applications, security features, middleboxes, etc.). Layer 7 is 
network end to end: this is what the Internet delivers. OPES as 
discussed by the IETF are layer 8. Layer 8 is to adapt the networked 
content to the receiver according to the expectations of the sender 
and to the demand of the receiver, or of a third party. So layer 8 
will deliver an apparent end to end interintelligibility (what the 
receiver can accept). It will actually adds intelligence to the dumb 
network, but not within the dumb network. Obviously there may be 
several hops on a connection. And several OPES shims involved.

The IETF OPES is an on-line filter calling out external hosts. This 
is a shared remote middlebox system. The ONES concept is a network of 
called-out hosts. They can mutually share into the provided service 
and be triggered by OPES outside of the end to end link. An example 
is an anti-spam service. I put an OPES on the I/O of my SMTP server. 
It calls-out an host which filters the spam I receive. It could 
alternatively call out an ONES (a network of hosts in relation with 
many similar OPES). They would dynamically detect a spam as a content 
sent to non related destinees, check the sending IP and block the 
message at all the participating call-out hosts, blocking the spam at 
all the OPES before the reach their SMTP clients.

jfc

At 17:08 12/04/2006, John Day wrote:

>>>enough, they might not have realized it if the CCITT had not 
>>>stolen what was called the Session Layer for Videotext.
>>>
>>>what wasn't.  (Other ISO committees standardize other things, so 
>>>to some degree there was a question as to where communications 
>>>stopped and applications started. A bit of a turf battle.)  This 
>>>was an intense and often esoteric debate about the nature of 
>>>applications and what was inside and outside "the OSI 
>>>environment."  (Amusingly, the only short name we had for the 
>>>discussion couldn't be used in any official minutes.  Everyone 
>>>referred to it as the "balls in/balls out problem.")  When I heard 
>>>what the solution was: the balls were on the line, I thought it 
>>>was a typical standards committee wimp out, but turns out to be 
>>>the right answer.
>>
>viewed as the purview of the AP, not the AE and hence outside the 
>OSI environment and the domain of other standards.  So in that sense 
>you are correct.  They did not consider it.
>
>>>(and potentially one or more instances of each).  So for example, 
>>>a reservation application, the AP, might have an AE for HTTP for 
>>>the interface to the user and an AE for a remote database protocol 
>>>to the reservation database (and multiple instances of both for 
>>>turn out to be special cases, where the AE IS the AP, i.e. there 
>>>is little or no "AP functionality" and there was generally one per 
>>>cnn.com, i.e. the AP, that is the thing being addressed.  There 
>>>are lots of applications all different that must be addressed and 
>>>they all use the same protocol.
>>>
>>>separate layers.  Which is how some of us build it.  (The 
>>>bellheads in OSI insisted on keeping the distinction because they 
>>>had used it for Videotext and later had based X.400 directly on 
>>>the Session Layer rather than use Presentation and ACSE.
>>>
>>>application and not common modules in the application protocol. 
>>>(In essence, they aren't "reentrant" and it adds unnecessary 
>>>complexity to separate them and make them "reentrant.")
>>>
>>>the application process which is much more flexible, simpler and more powerful.
>>
>>added services delivering, with various contextual modifications 
>>the "A" which was sent. Usage Networking is about delivering the 
>>"B" the user wanted in sending an "A", because an online extended 
>>service he chose obeyed the "A" to deliver "B". This is only 
>>feasible if the network is understood as a network operating system 
>>and if the network processing power is not on the "network end to 
>>network end", but on a ONES welded on the "user end to the user end".
>
>>the Internet can only be internationalized and not 
>>multilingualised. Why I cannot send in French, and you receive in 
>>English (except possibly under HTTP. Cf. RFC 3835, 4037, 4237). Why 
>>there are chapel disputes over the single authoritative root - 
>>leading to balkanization. Why the IAB cannot accept that when I 
>>click on the link you propose, I go to the page I want (otherwise 
>>hyperlinks are spam). The IETF tyranny comes from this necessary 
>>but uncompleted analysis.
>

---

From: John Day <[email-masked]>
Date: Wed, 12 Apr 2006 13:06:28 -0400

At 18:33 +0200 2006/04/12, JFC (Jefsey) Morfin wrote:
>- extended services. sender sends an A for the network to deliver a 
>B resulting from an internal or external intelligence, the receiver 
>may turn into a C calling on its own Intelligent Services Provider 
>extended services.

Now I understand.  How to allow the network to implement censorship, 
spying on individuals, and dissemination of misinformation.  There 
will be a good market for this.

>application. DNS is too. My email sorting plug-in is not.

Nor is it communications.

>(they can be different links under different technologies, 
>networking applications, security features, middleboxes, etc.). 
>Layer 7 is network end to end: this is what the Internet delivers. 
>OPES as discussed by the IETF are layer 8. Layer 8 is to adapt the 
>networked content to the receiver according to the expectations of 
>the sender and to the demand of the receiver, or of a third party. So

It is the "third party" part that I find the most interesting.  This 
is exactly what the PRC has been looking for.

>layer 8 will deliver an apparent end to end interintelligibility 
>(what the receiver can accept). It will

I assume you have already begun breeding Babelfish for this layer.

>actually adds intelligence to the dumb network, but not within the 
>dumb network. Obviously there may be several hops on a connection. 
>And several OPES shims involved.

Most definitely.

>is a shared remote middlebox system. The ONES concept is a network 
>of called-out hosts. They can mutually share into the provided 
>service and be triggered by OPES outside of the end to end link. An 
>example is an anti-spam service. I put an OPES on the I/O of my SMTP 
>server. It calls-out an host which filters the spam I receive. It 
>could alternatively call out an ONES (a network of hosts in relation 
>with many similar OPES). They would dynamically detect a spam as a 
>content sent to non related destinees,

I assume that "non-related" here means sent to destinees whose 
relation is unknown to the system.

>check the sending IP and block the message at all the participating 
>call-out hosts, blocking the spam at all the OPES before the reach 
>their SMTP clients.

You should probably contact Sirius Cybernetics as well, I think you 
are going to need De-focused Temporal Perception for this as well. 
They have it deployed in their elevators and it seems to work pretty 
well, at least from what I have read.

Take care,
John

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 13 Apr 2006 03:30:46 +0200

Dear John,
the ethic I share with most is to see the users' needs addressed as 
much as it is technically possible. The pupose of this list - as I 
understand it - is that it may not be the Internet case so possible 
solutions are to be found. I know the misison of the IETF is to 
support its own values in influencing "the ways people design, use 
and manage the Internet" (RFC 3935). This may lead to ethical 
conflicts. Discussing your point here may not be considered as 
appropriate (as I say: "I do not expect my telephone being 
democratic, I expect it working").

However the allusions you make are too important to be considered 
(you may know that I campaign for the users' demands and ethic issues 
to be considered adequately within the Internet standard process). 
IMHO every technology development can be used for good and for bad. 
Not carrying them on moral grounds is respectable. But, I observe it 
has never impeached someone else to carry them. I also observe a 
common perverse effect. It is to disserve the people one wants to 
protect: they do not benefit from their good usage and they have not 
the experience/tools to protect themselves against their bad usages.

Anyway, what I document here is of the digital ecosystem essence and 
is very old story. It belongs to the existing Internet architecture. 
It has its own dedicated WG. We can certainly discuss if it is or not 
to Tele/Datacommunications. I think not: I documented they _extend_ 
them into Digital Relations Services. This is why I said when I 
joined this list that I was interested in usage architecture.

I feel the problem the Internet architecture meets, and its future, 
is in adequately supporting network usage architecture. I observe 
that what I call the interapplication layers (and its extended 
services) are today everywhere but not consistently addressed by lack 
of clear identification and of net-OS analysis/proposition: from 
virtual hosts, NATs, middleboxes, OPES, etc. This is why I try to 
raise the question: "is this an issue for the IETF"? Is the IETF only 
dedicated to the TCP/IP component of the digital users relations? Or 
is it interested in addressing the technologies of the whole digital 
services convergence?

jfc

At 19:06 12/04/2006, John Day wrote:
>>example is an anti-spam service. I put an OPES on the I/O of my 
>>SMTP server. It calls-out an host which filters the spam I receive. 
>>It could alternatively call out an ONES (a network of hosts in 
>>relation with many similar OPES). They would dynamically detect a 
>>spam as a content sent to non related destinees,
>