Subject: SMTP Use Cases

From: "Martin Stecher" <[email-masked]>
Date: Fri, 22 Oct 2004 12:19:04 +0200

Hi,

mid of July there has been a short discussion whether we want
to add a Use Cases section to the SMTP adaptation draft or
create an extra document about SMTP use cases.

Maybe we first collect the use cases we feel important to
write about and then also consider the volume of that before
deciding where to put it.

Here are my first thoughts on SMTP use cases.
Please add and comment.

There are use cases for SMTP message content (1) and SMTP dialog
adaptation (2). And there are use cases where the message content
may have an influence on mail forwarding options or trigger
other side effects (3).

1. Examples for message content adaptation:

- Virus checking
- Other security policies (e.g. forbidden attachment types)
- Content Analyzes (classify content into categories, search for forbidden content)
- Translation of message text
- Filter Spam (pure content adaption may just mark the message, for other actions see below)
- Transform content to make it better readable on special mail clients (e.g. Blackberries)
- Encrypt emails or verify signature.

2. Short form of the examples for SMTP dialog adaptation I gave in my emai
on July 14, plus a new one:

- Validate "MAIL FROM"
- Validate "RCPT TO"
- Sender validation via IP, HELO, SenderID, etc.
- Resolve distribution lists

3. Examples for mail forwarding options or other side effects:

- Delay a message of a certain size or content
- Send virus notifications to others when virus has been detected
- Move email to a special queue (e.g. Spam queue)
- Drop a (spam) message
- Out of office replies

Regards
Martin

---

From: jfcm <[email-masked]>
Date: Fri, 22 Oct 2004 16:17:28 +0200

Martin,
I do not see any of these examples (which are much needed) being an OPES. 
They are middlebox (RFC 3234) services. None of them are on the fly 
protocol add-on functions in a store and foreward system.
jfc

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 22 Oct 2004 11:03:02 -0400

> - Move email to a special queue (e.g. Spam queue)

- Stripping of large attachments from emails, putting them on a Web
   server, and replace the attachment in email with a URL to that
   server file

(Wished I had that service lats time I connected through dial-up and 
received tons of PPT presentations in emails...)

-Markus

---

From: jfcm <[email-masked]>
Date: Fri, 22 Oct 2004 17:32:20 +0200

>   server, and replace the attachment in email with a URL to that

This is a first step ahead towards what I name "weemail" (and end of 
spam)  :-) This a firewall middlebox fonction. Certainly a good fonction. 
But is it an edge function? Why this content massaging (true for every mail 
service) would be specific to SMTP?

Why not to review the charter and talk of "mail services"? And review the 
reference to MTAs.
There actually tools (design, protocol, etc) and application to types of 
exchanges under serveral protocols.
jfc

---

From: "Alex Rousskov" <[email-masked]>
Date: Fri, 22 Oct 2004 10:08:53 -0600

> received tons of PPT presentations in emails...)

FWIW, good IMAP email clients already support that.
Your use case still makes sense for thin clients and such, of course.

Alex.

---

From: "Hilarie Orman" <[email-masked]>
Date: Fri, 22 Oct 2004 10:11:40 -0600

There's a technical reason for questioning whether or not OPES
is the right thing for SMTP, and I believe Martin once gave me
a reasonable answer, but I don't think it's ever been elucidated
on this list.  The question arises from SMTP being inherently
store-and-forward, as Morin points out.  Thus, one would think
the the "natural" architecture for handling it would be for the
OPES processor to simply run SMTP and forward the messages to
an SMTP server where the "service enhancements" can be applied.
That SMTP server can then forward the messages onward to the appropriate
"vanilla" SMTP servers.  So, why is OPES necessary?

I believe that Martin told me that it would be much easier for
developers to write OPES rules and modules for SMTP than to
write them for SMTP directly, and I suppose that makes sense if
OPES is deployed widely for HTTP and there is a base of developers
skilled in that environment.  Is that an accurate statement of
the intent of the OPES/SMTP proponents?  I think it would really
help if we could agree on an answer to the basic question (above).

Hilarie

---

From: "Hilarie Orman" <[email-masked]>
Date: Fri, 22 Oct 2004 10:18:03 -0600

I think all of the use cases are good, but I'd
like to point out that there's already a significant problem with
SMTP "enhancements".   The ISP that provides my IP connectivity
has severe email filters and they do not offer per user "customization".
Their implicit, unwritten, use policy is "by using our services
you agree to having us muck with your email in any way that pleases us."
Thus, I have to pay for a second ISP in order to get email services
without filtering.  That ISP does, however, sometimes impose filtering
even on "no filter" accounts, simply because their techs don't realize
that such accounts exist.  Recently the filtering caused me to be 
suspended from almost all IETF mailing lists.  Fortunately, they
lifted that particular filter when I talked to them about it; 
they'd forgotten it was there.

My point in this anecdote is that because there is no required API
for per account customization *by the customer* for SMTP filtering
today, the overall utility of SMTP is, in my opinion, drastically
reduced.  This is why I think that defining the protocol that lets
the user adjust the filtering rules is so important for SMTP.

When we began this work, I thought that the per account customization
for HTTP was very important, but not worth screaming about.  In the
intervening years HTTP has become more important to daily life, and I
think the issue is as important as for SMTP.  I would really like to
see some ideas on how to get this specified and set into standards
as we move forward with SMTP.

Hilarie

---

From: "Alex Rousskov" <[email-masked]>
Date: Fri, 22 Oct 2004 11:13:22 -0600

> help if we could agree on an answer to the basic question (above).

The reason we want OPES is so that we can reuse many things common to  
content adaptation, regardless of the protocol that the content came from.  
We do not want to answer content integrity, men-in-the-middle, or rules  
questions from scratch for every new protocol.

I may be repeating myself, but I still do not know how store-and-forward  
SMTP is different from whatever-you-want-to-call-it HTTP in the context of  
adapting content. Thus, for me, SMTP adaptation can be within OPES scope  
if HTTP adaptation is. Using your example above, exactly the same argument  
can be made for HTTP: why not forward the messages to an HTTP proxy where  
the "service enhancements" can be applied...

Alex.

---

From: "Alex Rousskov" <[email-masked]>
Date: Fri, 22 Oct 2004 11:19:35 -0600

> as we move forward with SMTP.

I think this plays well with P rules or similar standard to express  
filtering rules.
Most ISPs cannot offer rich customizations today because they would have  
to invest in a custom interface to support/maintain those customizations.  
If we give the world a common filtering language, the ISP can buy an  
off-the-shelf rules management tool and have users specify their  
preferences on the web (auto-converted to [P] rules that ISP's servers  
understand).

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 22 Oct 2004 13:32:13 -0400

> help if we could agree on an answer to the basic question (above).

Isn't an additional motivation that OPES allows you to forward partial 
application messages, i.e. only the parts needed by the callout server 
have to be forwarded (as opposed to the entire message)?

-Markus

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 22 Oct 2004 13:40:09 -0400

Alex Rousskov wrote:

> Most ISPs cannot offer rich customizations today because they would 
> have  to invest in a custom interface to support/maintain those 
> customizations.  If we give the world a common filtering language, the 
> ISP can buy an  off-the-shelf rules management tool and have users 
> specify their  preferences on the web (auto-converted to [P] rules that 
> ISP's servers  understand).

Agree. But that's what the email world has 'sieve' for. So we want to 
be careful to not re-invent the wheel (that's why Tony was suggesting 
to first compare 'sieve' to what we intend to do with 'P').

My email provider actually let's me specify 'sieve' rules, using 
either an "advanced" interface where I can put in my sieve rules in 
ascii, or via kind of a "wizard" interface.

Hilarie re-emphasized an important point, we want to keep that in mind.

-Markus

---

From: "Hilarie Orman" <[email-masked]>
Date: Fri, 22 Oct 2004 17:49:07 -0600

HTTP never had a store-and-forward protocol architecture, so all
the proxy stuff got tacked on.  SMTP dealt with it from the beginning
and already addressed the problems of MITM, tracing, etc.  It is,
in fact, the strawman reference model for much of our OPES discussion.

There's an odd recursive aspect to applying OPES to SMTP, and I think
it is important to clarify why SMTP will benefit from OPES, sort of
like asking why one's grandparents should buy their clothes at
Banana Republic (whatever).

Hilarie

-----Snippet of Original Message-----
From: Alex Rousskov
Sent: Friday, October 22, 2004 11:13 AM
Subject: Re: SMTP Use Cases

Alex.

---

From: jfcm <[email-masked]>
Date: Sat, 23 Oct 2004 02:52:38 +0200

I think we will never get Alex understand the problem. What he sees is an 
action on a message. Not the scope of that action. It is true that whatever 
the protocol a message (in one or several datagrams) is massaged like in 
any middlebox. The difference is thatit is not massage at the middlebox but 
at a distant server. The important action is the massaging (filtering, 
protocol to the server, update). Martin in the SMTP case see the things the 
same way.

I see the same thing, but in an architectural way. Either the idea is to 
stop having too many middleboxes and to keep the network intelligence at 
the edge, so the architectural end to end and dumb network/smart hosts can 
be protected. This is the IAB idea and we have to be very tought on the 
OPES definition as an "edge" service. Or we do not mind IAB, we address the 
need and we extend RFC 3234 with networked middleboxes (I recall that 
middleboxes can be virtual, so the filter of an OPES is a midlebox).

1. if we talk about OPES. there may be knowledge of the OPES action by the 
ends, but no dialog with both. In the case of an a-synchornous service 
multicast such as SMTP the only end to be informed is the nearest end. 
Also, by no means OPES can be on an MTA, only on UAs because the MTA by 
nature is not at the edge of the network. OPES can only be on the edge 
traffic. Not on the stored nor on inner network traffic.

2. if we talk of remote server supported middleboxes, we are totally free 
to do what we want. But these are no more OPES but ONES. This means Open 
Network Extended Services. We are then introducing intelligence within the 
network, what I _fully_ support, but which is far, far more complex to 
document. May I remind you RFC 2775: there is no objection to change 
everything in the network vision (and I DO think this necessary and urgent 
if we want to address the IAB concerns on Internet future) but this is 
another issue and I doubt this WG has the right people to engage a total 
rebuild of the Internet.

I can only repeat that the proposed examples are fine as services, not as 
OPES they are not. Also, that the new charter does not make any technical 
sense to me. Because OPES are at users plug and the work you want them to 
provide is at the power plant.

Or we decide that the architecture is end-to-mailserver + 
mailserver-to-end. The mail server is then an edge. But who is in control? 
Not the receiving end but the ISP mailserver manager. And we fall back in 
the situation described by Markus....
jfc

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 22 Oct 2004 22:26:55 -0400

Hilarie Orman wrote:

> it is important to clarify why SMTP will benefit from OPES, 

As I mentioned before - with OPES you can send parts of an 
applications message to the callout server, you're not forced to send 
the entire message. With SMTP, you would always have to sens the 
entire message. LEss efficient. Do I miss anything here?

Plus the additional - deployment/implementation specific - benefits 
Martin and Alex mentioned.

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 22 Oct 2004 21:45:22 -0600 (MDT)

On Fri, 22 Oct 2004, Markus Hofmann wrote:

> As I mentioned before - with OPES you can send parts of an applications 
> message to the callout server, you're not forced to send the entire message. 
> With SMTP, you would always have to sens the entire message. LEss efficient. 
> Do I miss anything here?

With SMTP, the adaptation box must know and speak SMTP. With OPES, the 
adaptation box must know and speak some OCP profile. OCP is designed 
for adaptations. SMTP is not. And the adaptation box does not have to 
learn new protocols to adapt messages they carry. One would not have 
to build a FooBar adaptation box to adapt FooBar protocol; with some 
lack, the old adaptation box can be used as-is.

Partial message adaptation is a side-effect. You are simply talking 
about an OCP profile that defines "content" in such a way that partial 
SMTP adaptation becomes possible. With some luck, partial HTTP 
adaptation may be possible with the same or very similar profile.

OPES makes some sense when we look at one application protocol in 
isolation (e.g., HTTP or SMTP). That's why ICAP is still alive. 
However, OPES true power is adaptation of multiple application 
protocols with little extra effort. That is, it scales with the number 
of application protocols. That scale is what current ICAP vendors 
struggle with.

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 22 Oct 2004 21:52:20 -0600 (MDT)

Jfc,

 	Since I cannot understand your objections, despite multiple 
serious attempts to do so, my suggestion would be for you to forward 
your new-charter-makes-no-sense objections to IESG. If IESG 
understands and agrees with your position, they might be able to 
explain it in a way that I can comprehend in order to help with fixing 
the charter. If not, we would not have to come back to this until the 
next charter revision.

Alex.

On Sat, 23 Oct 2004, jfcm wrote:

> the protocol a message (in one or several datagrams) is massaged like in any 
> middlebox. The difference is thatit is not massage at the middlebox but at a 
> distant server. The important action is the massaging (filtering, protocol to 
> the server, update). Martin in the SMTP case see the things the same way.
>
> I see the same thing, but in an architectural way. Either the idea is to stop 
> having too many middleboxes and to keep the network intelligence at the edge, 
> so the architectural end to end and dumb network/smart hosts can be 
> protected. This is the IAB idea and we have to be very tought on the OPES 
> definition as an "edge" service. Or we do not mind IAB, we address the need 
> and we extend RFC 3234 with networked middleboxes (I recall that middleboxes 
> can be virtual, so the filter of an OPES is a midlebox).
>
> multicast such as SMTP the only end to be informed is the nearest end. Also, 
> by no means OPES can be on an MTA, only on UAs because the MTA by nature is 
> not at the edge of the network. OPES can only be on the edge traffic. Not on 
> the stored nor on inner network traffic.
>
> 2. if we talk of remote server supported middleboxes, we are totally free to 
> do what we want. But these are no more OPES but ONES. This means Open Network 
> Extended Services. We are then introducing intelligence within the network, 
> what I _fully_ support, but which is far, far more complex to document. May I 
> remind you RFC 2775: there is no objection to change everything in the 
> network vision (and I DO think this necessary and urgent if we want to 
> address the IAB concerns on Internet future) but this is another issue and I 
> doubt this WG has the right people to engage a total rebuild of the Internet.
>
> Or we decide that the architecture is end-to-mailserver + mailserver-to-end. 
> The mail server is then an edge. But who is in control? Not the receiving end 
> but the ISP mailserver manager. And we fall back in the situation described 
> by Markus....
> jfc
>
>

---

From: jfcm <[email-masked]>
Date: Sat, 23 Oct 2004 17:36:15 +0200

At 04:26 23/10/2004, Markus Hofmann wrote:
>message to the callout server, you're not forced to send the entire 
>message. With SMTP, you would always have to sens the entire message. LEss 
>efficient. Do I miss anything here?

Dear Markus,
I am sorry but "I" miss something here.
- what has SMTP to do with this. SMTP has no callout server so there is no 
way it can send parts or the whole message to a callout server.
- I suppose that what you mean is the that callout server may work on parts 
of the content while most of the "value added" MTA systems would work on 
the complete content. I do not see the added interest. Please remember that 
SMTP permit many MTA to be involved on an traffic load balancing approach. 
Far more efficient to work on a local content than to send and receive it.

Your proposed OPES is a sendmail, postfix, qmail etc. front-end adding to 
their management complexity. Frankly I prefer developping a postfix module 
or even to try to understand the qmail license and patch system or to see 
what can be done with sendmail than to add management complexity ... All 
the more than spam (which is an architectural problem) will only be solved 
by an architectural solution, and since spam is a by-product of 
TCP/IP¨+SMTP complexity, one will most probably find its solution in 
simplification (please reread RFC 2775 on architecture) simplicity is of 
the essence.

I dont say that you are wrong with your examples, services, OPES interest, 
but that there is confusion and that you confuse protocol and content 
massaging, synchronous and asynchronous processes, Host and users etc. and 
that in some way you are right. But we need to know in which context we are 
: in RTF 2775 context or in a RFD 2775 new permitted architectural context 
- and then which one.  To be modelized and documented.
jfc

>Plus the additional - deployment/implementation specific - benefits Martin 
>and Alex mentioned.
>
>-Markus
>
>
>

---

From: jfcm <[email-masked]>
Date: Sat, 23 Oct 2004 15:52:22 +0200

Alex,
I know that you do not understand. From the very beginning your vision of 
an OPES is the vision of a front-end middlebox with an OCP link to 
a  remote server. You just explained this: the interest of that middlebox 
is that it can easily be adapted to any protocol. This vision is of real 
interest to patch protocols and to implement transitions. But it permits 
much more if used in a proper architectural way.

Now, you are able to understand that if what you work on is to be used in 
an architectural dead-end - whatever the cosmetic in describing it - you 
will waste your time and efforts. So the question is of importance to you.

Right now IETF is trying to understand if they are in such an architectural 
dead-end or not. This is plainly documented in the IAB RFC 3869  published 
a few weeks ago. This is plainly documented in IETF RFCs on IETF situation. 
This is plainly documented in the IETF debates initiated by Harald 
Alvestrand. This was plainly documented through ICANN early warning problem 
two years ago. This was plainly documented in the new economy quick 
blundering. This is plainly documented in the WSIS resolutions calling on 
Koffi Annan's experts. Always in the same way: a partial list of  problems 
without ever considering the deliveries, the call for help to people they 
do not want (money and Gov), the lack of understanding of what would 
trigger a positive response (that deliveries would match real needs).

The IAB documents the internet problems in RFC 3869: the lack of vision, of 
motivation and of funding for R&D. It also gives the reasons why: through 
what is missing in their document (they do not even allude to 
mutilingualism, to user or market demand). The real internet problem is an 
host centric architecture which does not respond the real world needs. The 
real needs and interest are usage centric. The IAB is clear about it: it 
identifies global access to information (host application) as THE internet 
service. This is a 1971 need (first commercial ISP bill in Feb. 1971). 
There is a very long that network marketers and service developpers know 
this is far more complex. Users also want services and full control. But 
how IETF will know it without market study? The IETF is producing Ford-T 
cars and meets some difficulties about organizing, funding, recruiting. At 
the present time it tries to understand how to best organize, get funding, 
motivate its members. Sometimes they will consider producing Mustang cars.

This is why there is a drop in R&D and funding, why IETF audience and money 
drop, why Stuart Lynn had to call on Govs for ICANN, why IAB now calls on 
Govs for R&D, why WSIS calls on Govs for an Internet governance review 
(please read RFC on IETF problems). For two centuries the world has used 
Gov control/monopolies. The web has made believe that we could use 
Internet's free datagram du to the lack of State protected economical 
model. This has initially worked because the USG warranted it, but its 
interest is not in warranting and funding the world's system (the WSIS has 
two problems: world system's governance and funding).

The loss of interest comes from the fact that no one sees big return from 
investing in the internet architecture. Only bandwidth value added people 
who see some saving while their revenues and margins drop. This is the 
reason of the new economy failure. This is the reason why no one will fund 
you for developing OCP. This is the reason why the WG loses momentum while 
it works on a real key issue. The searchers and investors question is 
really simple "what for?".

Some have understood the solution. Many have understood how to look for it 
(please reread RFC 2775).

Once again, what is concerned is not OCP, but where and how to use it.

I am not interested in documenting this to IESG. We made the diagnosis 
nearly 20 years ago from our real life commercial success. We documented 
the architectural reasons of such a success. At the time we were the world 
leader (Tymnet) when we were poorly purchased. We quitted and disbanded. I 
can tell you exactly how and when our world lost 30 years. And the 1987 
evening when we evaluated that there was no interest in wasting time to 
document the young IETF because real world and academic life, vision and 
budgets are so apart. The interest is that these 20 years permitted to 
validate and to deep our vision (through some huge success as M$ which 
partly used it, or some evolution such as the drop in bandwidth cost and 
ubiquity, but mostly in observing the problems met by OSI and then by the 
Internet - and the way they try to patch them, as with OPES). This is lame. 
Either you understand it and the opportunity is huge, or you do not want to 
accept it and you waste your time and energy.

Now, with the currently coming appliances hardware and FCC/Govs growing 
communication attitude, the future internet is at hand. It may not come 
from IETF nor from GPL etc. It may come from an US start-up, from a Major's 
understanding of the real musical market and economical model, it can come 
from an European workshop, it can come from a Chinese manufacturers 
consensus, or from an Indian engineers venture. Probably after a major 
collapse over a DoS, a DNS failure, a spam growth, a brilliant physing, or 
a real life catastrophe as Richard Clarke foresaw it, a big digital 
terrorist attack or a Govs fed-up at the ASCII internet US nexus (please 
note that I invent nothing. All this is fully documented in RFCs and in USG 
documents). All this will lead to competition in solutions, hence to a 
balkanization of the Internet (cf. Paul Vixie on the IETF general mailing 
list over IPv9 Chinese testing). This is why the only solution IMHO is to 
document Govs about the real life threats, imply them in solutions and 
demonstrate through real working system solutions.

In that future Internet, a distributed ubiquity of smart stand alone smart 
multi services $ 100 nodes over a continuity of various types of bandwidths 
by coopeting large concentrated operators (look at FCC policy) at a global 
$ 15 cost per month, the protocol will probably progressively switch from 
IP to something better (but compatibility will have to be maintained for a 
while) managed by a secure and versatile simple inter-user network 
operating system. OCP could be a good embryo of such an OS internal protocol.

jfc

At 05:52 23/10/2004, Alex Rousskov wrote:

> serious attempts to do so, my suggestion would be for you to forward your 
> new-charter-makes-no-sense objections to IESG. If IESG understands and 
> agrees with your position, they might be able to explain it in a way that 
> I can comprehend in order to help with fixing the charter. If not, we 
> would not have to come back to this until the next charter revision.
>
>Alex.
>
>>action on a message. Not the scope of that action. It is true that 
>>whatever the protocol a message (in one or several datagrams) is massaged 
>>like in any middlebox. The difference is thatit is not massage at the 
>>middlebox but at a distant server. The important action is the massaging 
>>(filtering, protocol to the server, update). Martin in the SMTP case see 
>>the things the same way.
>>
>>the edge, so the architectural end to end and dumb network/smart hosts 
>>can be protected. This is the IAB idea and we have to be very tought on 
>>the OPES definition as an "edge" service. Or we do not mind IAB, we 
>>address the need and we extend RFC 3234 with networked middleboxes (I 
>>recall that middleboxes can be virtual, so the filter of an OPES is a 
>>midlebox).
>>
>>1. if we talk about OPES. there may be knowledge of the OPES action by 
>>the ends, but no dialog with both. In the case of an a-synchornous 
>>service multicast such as SMTP the only end to be informed is the nearest 
>>end. Also, by no means OPES can be on an MTA, only on UAs because the MTA 
>>by nature is not at the edge of the network. OPES can only be on the edge 
>>Network Extended Services. We are then introducing intelligence within 
>>the network, what I _fully_ support, but which is far, far more complex 
>>to document. May I remind you RFC 2775: there is no objection to change 
>>everything in the network vision (and I DO think this necessary and 
>>urgent if we want to address the IAB concerns on Internet future) but 
>>this is another issue and I doubt this WG has the right people to engage 
>>a total rebuild of the Internet.
>>
>>mailserver-to-end. The mail server is then an edge. But who is in 
>>control? Not the receiving end but the ISP mailserver manager. And we 
>>fall back in the situation described by Markus....
>>jfc
>>
>>

---

From: Markus Hofmann <[email-masked]>
Date: Sat, 23 Oct 2004 12:21:51 -0400

The OPES WG mailing list is *not* the place to discuss fundamental 
architecture/design issues of the general Internet and how the general 
Internet should evolve. While these discussions are important, 
interesting and (sometimes) fun, please move them to the general IETF 
mailing list.

OPES scope and architecture have been discussed a while ago and are 
documented in the respective RFCs and our charter. Discussions on this 
mailing list will be within these boundaries. More general and 
fundamental discussions should be move to more approriate places.

Thanks,
  Markus

jfcm wrote:
> 
> Alex,
> I know that you do not understand. From the very beginning your vision 
> of an OPES is the vision of a front-end middlebox with an OCP link to a  
> remote server. You just explained this: the interest of that middlebox 
> Now, you are able to understand that if what you work on is to be used 
> in an architectural dead-end - whatever the cosmetic in describing it - 
> you will waste your time and efforts. So the question is of importance 
> to you.
> 
> Right now IETF is trying to understand if they are in such an 
> architectural dead-end or not. This is plainly documented in the IAB RFC 
> 3869  published a few weeks ago. This is plainly documented in IETF RFCs 
> on IETF situation. This is plainly documented in the IETF debates 
> initiated by Harald Alvestrand. This was plainly documented through 
> ICANN early warning problem two years ago. This was plainly documented 
> in the new economy quick blundering. This is plainly documented in the 
> WSIS resolutions calling on Koffi Annan's experts. Always in the same 
> way: a partial list of  problems without ever considering the 
> deliveries, the call for help to people they do not want (money and 
> Gov), the lack of understanding of what would trigger a positive 
> response (that deliveries would match real needs).
> 
> The IAB documents the internet problems in RFC 3869: the lack of vision, 
> of motivation and of funding for R&D. It also gives the reasons why: 
> through what is missing in their document (they do not even allude to 
> mutilingualism, to user or market demand). The real internet problem is 
> an host centric architecture which does not respond the real world 
> needs. The real needs and interest are usage centric. The IAB is clear 
> about it: it identifies global access to information (host application) 
> as THE internet service. This is a 1971 need (first commercial ISP bill 
> in Feb. 1971). There is a very long that network marketers and service 
> developpers know this is far more complex. Users also want services and 
> full control. But how IETF will know it without market study? The IETF 
> is producing Ford-T cars and meets some difficulties about organizing, 
> funding, recruiting. At the present time it tries to understand how to 
> best organize, get funding, motivate its members. Sometimes they will 
> consider producing Mustang cars.
> 
> This is why there is a drop in R&D and funding, why IETF audience and 
> money drop, why Stuart Lynn had to call on Govs for ICANN, why IAB now 
> calls on Govs for R&D, why WSIS calls on Govs for an Internet governance 
> review (please read RFC on IETF problems). For two centuries the world 
> has used Gov control/monopolies. The web has made believe that we could 
> use Internet's free datagram du to the lack of State protected 
> economical model. This has initially worked because the USG warranted 
> it, but its interest is not in warranting and funding the world's system 
> (the WSIS has two problems: world system's governance and funding).
> 
> The loss of interest comes from the fact that no one sees big return 
> from investing in the internet architecture. Only bandwidth value added 
> people who see some saving while their revenues and margins drop. This 
> is the reason of the new economy failure. This is the reason why no one 
> will fund you for developing OCP. This is the reason why the WG loses 
> momentum while it works on a real key issue. The searchers and investors 
> question is really simple "what for?".
> 
> Some have understood the solution. Many have understood how to look for 
> it (please reread RFC 2775).
> 
> the architectural reasons of such a success. At the time we were the 
> world leader (Tymnet) when we were poorly purchased. We quitted and 
> disbanded. I can tell you exactly how and when our world lost 30 years. 
> And the 1987 evening when we evaluated that there was no interest in 
> wasting time to document the young IETF because real world and academic 
> life, vision and budgets are so apart. The interest is that these 20 
> years permitted to validate and to deep our vision (through some huge 
> success as M$ which partly used it, or some evolution such as the drop 
> in bandwidth cost and ubiquity, but mostly in observing the problems met 
> by OSI and then by the Internet - and the way they try to patch them, as 
> with OPES). This is lame. Either you understand it and the opportunity 
> is huge, or you do not want to accept it and you waste your time and 
> energy.
> 
> from IETF nor from GPL etc. It may come from an US start-up, from a 
> Major's understanding of the real musical market and economical model, 
> it can come from an European workshop, it can come from a Chinese 
> manufacturers consensus, or from an Indian engineers venture. Probably 
> after a major collapse over a DoS, a DNS failure, a spam growth, a 
> brilliant physing, or a real life catastrophe as Richard Clarke foresaw 
> it, a big digital terrorist attack or a Govs fed-up at the ASCII 
> internet US nexus (please note that I invent nothing. All this is fully 
> documented in RFCs and in USG documents). All this will lead to 
> competition in solutions, hence to a balkanization of the Internet (cf. 
> Paul Vixie on the IETF general mailing list over IPv9 Chinese testing). 
> This is why the only solution IMHO is to document Govs about the real 
> life threats, imply them in solutions and demonstrate through real 
> working system solutions.
> 
> In that future Internet, a distributed ubiquity of smart stand alone 
> smart multi services $ 100 nodes over a continuity of various types of 
> bandwidths by coopeting large concentrated operators (look at FCC 
> policy) at a global $ 15 cost per month, the protocol will probably 
> progressively switch from IP to something better (but compatibility will 
> have to be maintained for a while) managed by a secure and versatile 
> simple inter-user network operating system. OCP could be a good embryo 
> of such an OS internal protocol.
> 
> jfc
> 
> 
> 
> 
>>> I think we will never get Alex understand the problem. What he sees 
>>> is an action on a message. Not the scope of that action. It is true 
>>> that whatever the protocol a message (in one or several datagrams) is 
>>> massaged like in any middlebox. The difference is thatit is not 
>>> massage at the middlebox but at a distant server. The important 
>>> action is the massaging (filtering, protocol to the server, update). 
>>> Martin in the SMTP case see the things the same way.
>>>
>>> I see the same thing, but in an architectural way. Either the idea is 
>>> to stop having too many middleboxes and to keep the network 
>>> intelligence at the edge, so the architectural end to end and dumb 
>>> network/smart hosts can be protected. This is the IAB idea and we 
>>> have to be very tought on the OPES definition as an "edge" service. 
>>> Or we do not mind IAB, we address the need and we extend RFC 3234 
>>> with networked middleboxes (I recall that middleboxes can be virtual, 
>>> so the filter of an OPES is a midlebox).
>>>
>>> 1. if we talk about OPES. there may be knowledge of the OPES action 
>>> by the ends, but no dialog with both. In the case of an a-synchornous 
>>> service multicast such as SMTP the only end to be informed is the 
>>> nearest end. Also, by no means OPES can be on an MTA, only on UAs 
>>> because the MTA by nature is not at the edge of the network. OPES can 
>>> only be on the edge traffic. Not on the stored nor on inner network 
>>> traffic.
>>>
>>> 2. if we talk of remote server supported middleboxes, we are totally 
>>> free to do what we want. But these are no more OPES but ONES. This 
>>> means Open Network Extended Services. We are then introducing 
>>> intelligence within the network, what I _fully_ support, but which is 
>>> far, far more complex to document. May I remind you RFC 2775: there 
>>> is no objection to change everything in the network vision (and I DO 
>>> think this necessary and urgent if we want to address the IAB 
>>> concerns on Internet future) but this is another issue and I doubt 
>>> this WG has the right people to engage a total rebuild of the Internet.
>>>
>>> I can only repeat that the proposed examples are fine as services, 
>>> not as OPES they are not. Also, that the new charter does not make 
>>> any technical sense to me. Because OPES are at users plug and the 
>>> work you want them to provide is at the power plant.
>>>