>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@xxxxxxxxxxxxx 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf