Re: Last Call: 'Procedures for protocol extensions and variations' to BC

At 21:56 05/09/2006, Sam Hartman wrote:
> To be clear, I think I'm documenting what is a long-standing consensus
> in the IETF.  And I do consider it a bug that HTTP does not require
> TCP.  It's typical for protocols to require a transport.  For example
> , I believe SIP requires UDP (and possibly TCP).  Kerberos requires
> TCP.
Why?

What you want to say is that HTTP should require the features of a 
TCP or UDP like protocol. When Tymnet supported TCP to the Vienna 
University where they imagined the IP Clusters to match the offered 
possibilities, TCP was dismembered, transformed into bytes + metadata 
under Tymnet II protocol to reach the IRCs and cross the Atlantic and 
Europe. They were in turn passed under X.25 by Radio Austria to the 
University. The same when they converted 2780 or 3270 to T.II and 
then to X.25 or to other protocols. This flexibility came from what 
you want: the specification by the upper layer of the lower layer 
deliverables.
We want:
- the data (basic service of connections)
- the metadata (value added service of communications)
- the inferentiation (extended services of relations) which supports 
the rebuild of the lower layers.
You want to specify what the lower layers are to deliver. Not the way 
they are to make it. When Berner-Lee shopped for datagrams, X.25 
would have probably be better, but it was rated at real commercial 
price and too expensive for the CERN (and the US deregulation had not 
helped smoothing costs and rates, in the US side. The Internet 
economy without economic model was more attractive, but we now have 
the economic resulting problem).
This is what OPES really are about. But the WG-OPES just considered 
one edge (OPES to reach-out servers), they did not want to network 
these servers at inter-server layer and build the ONES (open network 
extended services). Extended services permits to zap, change or 
create data for the receiving party so it receives what the sending 
party wanted it to receive, not necessarily what it was sent.
You send me a mail. If we are basic end to end, I must print in 
synchronously. If we are value added end to end, the mail is stored 
and forwarded (or more cleverly stored and retrieved). If we are 
extended brain to brain, you send it in English and I read it in 
correct French.
A human language is a brain to brain/CPU protocol. Until now you 
needed ietf-languages(_at_)alvestrand(_dot_)no like debates to differentiate 
languages. Now, if a n-gram language recognition algorithm is able to 
make a difference there are two languages.
The way you phrase your idea, you look saying what Unicode people 
say: to speak together people _need_ TCP/IP, therefore Unicode 
English globalization, and therefore RFC 3066 Bis langtags, and 
therefore a discrimination between primary languages and others. I am 
sorry, a few years before the IETF and terminal spoke HTTP to Web 
servers, (may be not a few years after :-)) people used to speak 
English, French, Tamil, .... they then started using data network, 
they organised on a language basis, in a way langtag could of help, 
utilizing appropriate technologies (Radio, TV, mobiles, PCs) where 
TCP is one of the solutions.
If I am personally determined on the languages matter, it is because 
they are our (human, upper layer) protocols and therefore command the 
lower layer Internet protocols and architecture and lead their 
innovation. When you develop the transport layer, you want it to 
support HTTP. You even want to standardise that it is a MUST. The 
same you do not want the lower layer (HTTP, HTML, XML, CLDR, etc.) to 
limit the upper layer (languages), you want the lower layer to 
support the requirement of the upper layer. Human languages demand a 
proper support from HTTP, SMTP, etc. which in turn demands a proper 
service from TCP, which in turn expects a proper service from IP. Not 
the other way around.
Because extended services will be much demanding on value added 
services and protocols, which in turn have been much demanding on 
physical connection, this a good way to make the Internet 
architecture progress.
Cheers.
jfc


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf