Re: Normalisation and matching

At 15:45 13/08/03, Mark Davis wrote:
>It does cost a bit more, since you do have to check each character
>[only in House Republican fancy does increasing (government spending)
>reduce size (of government)]. But depending on how much other
>processing is going on, it may or may not be significant. In parsing
>XML, for example, it is not.


Were there not any attempt sometime to modelize the different layers 
involved in such things (without going into a complete network architecture)?

All these problems seems addressable by OPES (open pluggable edge services) 
now under finalization.

I agree most consider the internet as a dump network/smart host approach vs 
smart network/dumb host telecoms vision. Could we not think again and as 
NGN will help doing "smart network/smart host"? OPES just start permiting 
it (see PS of this post). We can imagine mail services will simply 
subscribe to a converting OPES until they update and aggregate the 
necessary solutions.

I bored the WG-OPES with the requirment to support the DNS. IDNA does not 
address the real operators demand: ML.ML. There is no problem in having 
ISPs including the filtering in/out of the Chinese TLDs into ".com" or 
".net" without using DNAMES. What OPES can do in the RHS they can also do 
it on the LHS.

My own old proposition (my job before IETF was created :-) is just the next 
step ahead; it is to internetwork OPES into ONES (open network extended 
services) i.e. interactive networks/host services to the relations 
of  community. They started in the 80s (Swft, SIta, Visa, Amadeus, etc.) 
and were culturally blocked by OSI because the network continuity was no 
more win/win (sorry:  smart/smart). This means that OPES can be networked 
and provide an upper inter-application layer for fancy community services 
such as anti-spam meta directory, classment, ACKs, etc. what might help a 
quick dissemination.

IMHO we have to get the internet a little bit rennovative. Mail is the 
leading applictation. This is a opportunity which does not shake the old 
RFCs and permits to address the real user demands.

In this regards IDNA is an extremely interesting contribution. It shown 
that we can really enhance the network services (real operations) in 
encapsulating the current solution into an innvatve layer. This is the key 
of the network evolution. This permits to make the technology grow and 
maintain different levels of evolution together. When you need to have IDNA 
you have the IDNA layer, when iti s builtin in the OS you do not need 
anymore if you need the ML.ML, the OPES "out-plug" will take care until the 
DNS servers supports it...

jfc

For those not familiar with OPES just think of them as a smart wall plug. 
There is a "filter" (the dispatcher) were you put the rules you want. When 
a rule is triggered the data are sent under OCP to one or several servers 
to be massaged and returned. The process is transparent to the other end or 
not.

My proposed generalization as ONES has initially created discussions to 
know if they were part or not of the OPES. They are above. It means that 
OPES servers (those managing the information) are networked and may 
interact in function of the information they worl on and may even reroute 
the data mong themselves. There is also another controversy about the 
possible place of the dispatcher irt the application and the socket (IAB 
asked OPES to address the proxy based applications).

The debate was also the level of OCP from above XML down to a replacement 
ot IP. The final approach is to keep this neutral/adaptable as much as 
possible - I must say that I partly skipped the finalization of OCP by 
personnal overload - and I am more interested in the global architecture 
aspects/defintion.

What is of niterest in there is that OPES was initially supposed to address 
HTTP flows and that from start everyone added SMTP. IMHO this permits to 
_investigate_ (I say no more) all the forms possible RMTP (Rich Mail)