Subject: Re: Last Call: 'Procedures for protocol extensions and variations' to BCP (draft-carpenter-protocol-extensions)

From: Sam Hartman <[email-masked]>
Date: Tue, 05 Sep 2006 13:27:45 -0400

So, I was reading Brian's draft and I noticed that it talks a lot
about interoperability, but does not actually define interoperability.

As discussed in a recent IESG appeal, it's not clear that we have a
clear statement of our interoperability goals.  There's some text in
section 4 of RFC 2026, but we seem to actually want to go farther than
that text.

I propose that we add a definition of interoperability to Brian's
document.  In particular, we want to talk about our desire that all
implementations of one role of an IETF spec interoperate (at least
with regard to mandatory features) with implementations of
corresponding roles.  For example if we have a client-server protocol,
then you should be able to take any client and have it work with any
server at least for the mandatory parts of the protocol.  There are a
lot of complexities--for example while we hope every IP stack works
with every other IP stack, two machines may not share a common
upper-layer protocol or application protocol.  But I think we should
try and write down the core concept of this.

If people would find this useful I can try to write text.

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 05 Sep 2006 13:27:45 -0400

---

From: Jefsey_Morfin <[email-masked]>
Date: Tue, 05 Sep 2006 20:22:55 +0200

Sam,
this question is important and interesting.

IMHO there are two different types of interoperablities, which in 
turm makes billions of them: you have interoperability (direct plug) 
and metainteroperablity (the current through the plug can 
interoperate through a converter when the plugs are of different 
format). The end to end interoperability of the network devices, and 
the brain to brain interintelligbility of the network users.

This is a major issue I am quite digging into, because this is also 
true within the inner data structure. For example, if you define a 
variable as a string, you cannot use a number. But in some cases the 
number can be a pointer to a string. Interoperbility between strings 
and numbers. This is for example ISO 3166 which codes the names of 
countries (not countries) and ISO 639 the name of languages. What 
real sense makes a langtag when people come and say these are details 
conceived by politics?

Since a data can be a metadata for other data, this is an infinite 
possible chain. Interoperability is the chaining. I call it for the 
time being, the syllodata (gathering data) "shared layer?" by the 
metadata and the data (a smart dioptre). I my network model the most 
important layer is the interapplicative layer (extended services, my 
job for 20 years). These two edge shims are quite important because 
this where the OPES or security are. If a system have stable and 
secure syllodata (the mortar), one can think it will be difficult to 
break but this mortar which interlink has actually a name: 
"inteligence" (what interlinks). You see quickly that even if you 
have simple conditional interlinks, if you are recursive you can have 
immensely complex system. This is where W3C semantic web and XML do 
not work. They are mono-Internet defaulting to a flat space. Just an 
hyperlink. Rigid end to end interoperability. Now, think about 
smartlinks and you enter the distributed reality. This is also where 
is operated the digital decoherence (on one side you have information 
unsecure, multiple, repated quantums of data [datagrams] and on the 
other side you have stable, readable, copyable files, music, mails.

What is also interesting is to compare this concept with the 
infradata (internal data on the data) and the paradata (the data 
about the way the data are - but not permanent), the archidata (the 
permanent structure of the data), the philodata (what makes data to 
fit the metadata). You then realise that the definition-information 
couple is actually "intelligatum", a [definition -[inferentiation]- 
information] trilogy. You can start from definition you have 
induction, from information you have deduction, and from 
inferentiation you have abduction.

I think it is very important for network protocols, because the more 
their interoperability scales the more global they are. For example 
"From:" has a low scalability (language, function). But "True" has an 
high degree of scalability. But our common thiking makes is to be 
binary (yes/not, 0/1). This blurs our thinking and our mutual 
interoperability (protocols). Reality is yes/not/possible with all 
the possible gradations. There is a South-American Indian language 
which is ternary (Aymara). Kids think complex mathematics very easly.

Just a small quick attempt at interoperability.
I would be interested by your comments.
jfc

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 5 Sep 2006 14:39:34 -0400

On 9/5/06, Sam Hartman <[email-masked]> wrote:
> There are a
> upper-layer protocol or application protocol.

I worry that such text will encourage sprawling specifications that
make requirements across many layers. I think the example you give is
a little misleading, since it can be harmful for specifications to
make requirements on lower layers as well. For example, HTTP requires
a reliable transport, but I think it's good that RFC2616 does not
include text like "HTTP implementations MUST support TCP/IP, but may
support other transport protocols".

In other words, universal interoperability will not be achieved by
making RFC2119 demands in documents. It can be achieved by writing
small documents that confine themselves to one layer.

-- 

Robert Sayre

---

From: Sam Hartman <[email-masked]>
Date: Tue, 05 Sep 2006 15:56:33 -0400

>>>>> "Robert" == Robert Sayre <[email-masked]> writes:

    Robert> On 9/5/06, Sam Hartman <[email-masked]> wrote:
    >>  There are a lot of complexities--for example while we hope
    >> every IP stack works with every other IP stack, two machines
    >> may not share a common upper-layer protocol or application
    >> protocol.

    Robert> I worry that such text will encourage sprawling
    Robert> specifications that make requirements across many
    Robert> layers. I think the example you give is a little
    Robert> misleading, since it can be harmful for specifications to
    Robert> make requirements on lower layers as well. For example,
    Robert> HTTP requires a reliable transport, but I think it's good
    Robert> that RFC2616 does not include text like "HTTP
    Robert> implementations MUST support TCP/IP, but may support other
    Robert> transport protocols".

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.

---

From: Jefsey_Morfin <[email-masked]>
Date: Tue, 05 Sep 2006 23:50:58 +0200

>, I believe SIP requires UDP (and possibly TCP).  Kerberos requires

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 [email-masked] 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

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 06 Sep 2006 01:42:10 +0200

Sam Hartman wrote:

 [definition of interoperability] 
> As discussed in a recent IESG appeal, it's not clear that
> we have a clear statement of our interoperability goals.
> There's some text in section 4 of RFC 2026, but we seem to
> actually want to go farther than that text.
[...]
> If people would find this useful I can try to write text.

If you have something in mind, sure, it would be very useful.
And not necessarily limited to Brian's draft, it's also
related to http://article.gmane.org/gmane.ietf.general/19269

Frank

---

From: Sam Hartman <[email-masked]>
Date: Tue, 05 Sep 2006 23:52:51 -0400

>>>>> "Jefsey" == Jefsey Morfin <[email-masked]> writes:

    Jefsey> 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.

    Jefsey> Why?

    Jefsey> What you want to say is that HTTP should require the
    Jefsey> features of a TCP or UDP like protocol. 

Remember that interoperabality is defined by RFC 2026 in terms of the
ability to exchange one implementation for another.

  What I want to be able to do is to make a resource available via
http, and if I use only the mandatory features of the http spec, know
that you can resolve the URL regardless of what http implementation
you use.

I want to be able to give you a URL and have you resolve it.  That
only works if we speak the same transport protocol.

I want people to be able to reference HTTP and get interoperability,
not to have to write a profile of http.

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 5 Sep 2006 22:07:49 -0700

Hi -

> From: "Sam Hartman" <[email-masked]>
...
> Sent: Tuesday, September 05, 2006 8:52 PM
> Subject: Re: Last Call: 'Procedures for protocol extensions and variations'to BCP (draft-carpenter-protocol-extensions)
...
> only works if we speak the same transport protocol.

Sufficient, but not necessary.  It wasn't *that* long ago that 
transport-layer gateways were sometimes necessary to provide
the glue between IP-centric and other networking technologies.

> not to have to write a profile of http.

Defining the "MUST implement" features of HTTP results in a profile,
at least as the term was used in ISO / ITU-land.

In IETF-speak, describing the use of HTTP with a particular transport is
an "applicability statement".  Including an applicability statement in a
protocol specification can be a reasonable thing to do.  It's also reasonable
to talk about "interoperability" at the level of an applicability statement.

However, I think it would be a mistake to lose the current sense of
interoperability in terms of implementations' (lower) service interfaces.
Preserving those boundaries is essential to maintaining the modularity
of specification (and potentially of implementation) we need to keep
our sanity.

Randy

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 6 Sep 2006 01:58:58 -0400

> only works if we speak the same transport protocol.

Disagree. The Internet is pretty compelling, so proxies can and do
bridge transport protocols. Applications using the HTTP stack don't
need to know or care about the lower level.

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Sep 2006 11:22:52 +0200

Sam gave me a heads up this comment was coming (on the last day
of the Last Call, as it happens) so I had the chance to think about
it overnight.

We certainly could use clarity in this area. I also have some comments
about the meaning of interoperable implementations in
draft-carpenter-rfc2026-critique-02 (re Section 4.1.2 of RFC2026),
and there is thinking about how to report interoperability
in draft-ietf-newtrk-interop-reports-00.txt (expired, but I am
hoping more work will be done on this topic).

I'm a little concerned whether there is anything we can say in few
enough words to fit into the flow of draft-carpenter-protocol-extensions.

As co-author, I'm waiting for advice from the responsible AD (Ross Callon)
whether to add some text or not.

     Brian

---

From: Jefsey_Morfin <[email-masked]>
Date: Wed, 06 Sep 2006 12:54:06 +0200

>not to have to write a profile of http.

Sam,
there are several ways to understand your exact concern.

Let me keep considering the network ecology. This is the real issue 
we have with interoperability , i.e. the inner structure.

- either you consider the Internet as Harald Alvestrand considers it 
in RFC 3935: something the IETF leaders influence the building along 
their values. This vision is OK with me as long as this Internet is 
one system among others. Ex. TCP/IP vs. OSI. You can decide to 
constrain it to force the inner interoperability its unique 
governance wants. As does Harald with languages and you would with 
HTTP. Every time you give an URL you are to reach the same site. As 
also the IGF still considers the things: every time you give an URL 
you hope you reach the same site.

- or you consider the digital system as it is: a living global mess 
with many technologies, bugs, conflicts, etc., with its own ecology 
(the way it usually reacts to something). Every time you give an URL 
you do not know if you will reach the same site. So you organise 
yourself to preserve and develop interoperability and increase your 
chances, depending on your contexts.

Obviously the cybernetics of a closed top system (as in the first 
vision above, the vision of the Internet until now) is simpler and 
easier. You can delegate compatibility, security, compliance, etc. to 
lower layers. You are the root. This is the Plato's paradigm: the 
death, the living, and the pilot (kubernetes). You are the captain of 
your Internet ship.

The extended cybernetics of Plato's extended paradigm is far more 
complex (and more intellectually rewarding): there are pilots a 
plenty, each with his own ship. So the problem is not really internal 
interoperability to a single network of networks governance. It is 
the mutual interoperability within the intergovernance of billions of 
metanetworks on the single digital ecosystem messy supernetwork of 
the thousands of infrastructural networks. The networks' network's 
networks. There are three possibilities:

- either all the ships make a fleet you can lead in an autocratic 
"Admiralty Way"
- either they are a convoy and you try to influence them to sail in a 
similar (more or less democratic) way without too many collisions
- or they are a shipping with captains minding their own business you 
can inform of the difficulties ahead and of your own course.

It means that in the first case you decide of the network and for 
others: you impose your own interoperability. In the second case you 
discover the ecosystem and your companions law and you suggest what 
we can do to manage interoperability. In the third case you want to 
make a model of the ecosystem and of its risks and advantages, and 
you carry your own development concerting with other about 
interoperability, building it on your side if they do not mind and 
you need it, fighting others when they want to impose limits hurting 
you. This is the same as local trade, international guilds, and WTO 
for commerce.

To come back to RFC 3066 showcase of the issue. There is no 
opposition between Harlad's vision and mine. They are complementary, 
each at its own layer. Globalization of the ASCII Internet is OK, 
because Globalization is localised: each language is to be globalized 
the same as English is for the ASCII Internet. So, when the WSIS 
decided that the Internet is an USG issue, it localised the Internet 
and there is no more conflict  [oddily, you approved RFC 3066 a 
couple of hours later on]. The US/Internet practice can perfectly 
impose its own local vision of interoperability. And at the same 
time, other externets (external networks look alike) can have their 
own vision (my MDRS for example, or China for the DNS). The problem 
is the inter-externet interoperability. In the mono-Internet current 
IETF vision, interoperability is defined by RFC 2026 as an internal 
interoperability. All my dispute is about external interoperability. 
As simple way to address this problem is to accept the concept of a 
Multi-Internet, making the external mono-Internet interoperability, 
an internal interoperability issue of the Multi-Internet.

Once you have done this (what is perfectly in line with the way to 
resolve a problem of Brian's RFC 1958) you only consider gradations 
in interoperability and you can document a Bayesian interoperability. 
There you will find solutions for people to reach the URL you wanted 
them to want to access (which may not be the one you gave, but the 
one which is the one they need to understand what you want to 
convey). You have no more a root, but you worked out a garden out of 
the forest of the digital ecosystem. This is in the DNS area what 
ICANN asked the IETF to experiment in its ICP-3 document. IETF was 
not interested. We carried this experimentation. It shown that the 
current Internet technology can easily support it and that it is 
probably the only way for it to develop, uncoupling the developments 
of its various externets and layers.

All the best.
jfc

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Sep 2006 09:30:24 -0400

Jefsey> At 05:52 06/09/2006, Sam Hartman wrote:
    >> I want to be able to give you a URL and have you resolve it.
    >> That only works if we speak the same transport protocol.
    >> 
    >> I want people to be able to reference HTTP and get
    >> interoperability, not to have to write a profile of http.

    Jefsey> Sam, there are several ways to understand your exact
    Jefsey> concern.

    Jefsey> Let me keep considering the network ecology. This is the
    Jefsey> real issue we have with interoperability , i.e. the inner
    Jefsey> structure.

    Jefsey> - either you consider the Internet as Harald Alvestrand
    Jefsey> considers it in RFC 3935: something the IETF leaders
    Jefsey> influence the building along their values. This vision is
    Jefsey> OK with me as long as this Internet is one system among
    Jefsey> others. Ex. TCP/IP vs. OSI. You can decide to constrain it
    Jefsey> to force the inner interoperability its unique governance
    Jefsey> wants. As does Harald with languages and you would with
    Jefsey> HTTP. Every time you give an URL you are to reach the same
    Jefsey> site. As also the IGF still considers the things: every
    Jefsey> time you give an URL you hope you reach the same site.

    Jefsey> - or you consider the digital system as it is: a living
    Jefsey> global mess with many technologies, bugs, conflicts, etc.,
    Jefsey> with its own ecology (the way it usually reacts to
    Jefsey> something). Every time you give an URL you do not know if
    Jefsey> you will reach the same site. So you organise yourself to
    Jefsey> preserve and develop interoperability and increase your
    Jefsey> chances, depending on your contexts.
[Apologies to Harald.  I realize you don't run the Internet any more
and realize I'm taking your name in veighn:-)]

I want something in the middle.

If I fully embrace your vision, I end up with something far more
complicated than is necessary, although I will admit that it has
significant intellectual appeal.  There's actually a lot of
interesting science fiction written about network models similar to
what you are looking at.  I'm not intending to be pejorative by saying
that people are writing science fiction about it.  However I don't
think we understand how to engineer a network like that today and I
think that if we tried to design such a network we'd make a mess.

However, if we try and design the Internet that you think harald wants
but we do so with our eyes open, I think we can get somewhere in the
middle, somewhere that balances complexity against functionality.  We
use the ecological forces.  As we see specific problems that people
actually want to solve, we make changes to Harald's Internet to solve
them.  We try to be moderately ecologically focused in our thinking.
For example, when we see NAT issues in one network management
application, we ask ourselves whether the same problem will pop up
elsewhere (Hi, Eliot).  We make sure that things are extensible so
that we can change them.  

I understand you're trying to get us to do this.  I think though, you
are too forward thinking and your work is not motivated enough by
specific real-world problems.  Let's take your language tags work.  If
you had come to us with a specific application that was well enough
thought out that we could understand how it works even with users
menting their own languages, we would have considered your needs more
seriously.  But as your problem was presented, it was very much a pure
research problem not an engineering problem.  This is the IETF not the
IRTF and so we will make the valid engineering decision to limit
complexity rather than enable research.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Sep 2006 09:50:41 -0400

>> That only works if we speak the same transport protocol.

    Robert> Disagree. The Internet is pretty compelling, so proxies
    Robert> can and do bridge transport protocols. Applications using
    Robert> the HTTP stack don't need to know or care about the lower
    Robert> level.
I wouldn't mind writing the language in such a way that this
requirement could be met by proxies.  I don't see how to do that as an
implementation requirement though--and deployment requirements about
supporting the same transport would be completely inappropriate for
the IETF to make for HTTP.

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 6 Sep 2006 10:04:58 -0400

On 9/6/06, Sam Hartman <[email-masked]> wrote:
> requirement could be met by proxies.

I'm not sure what you want to write. Frankly, it seems like you're
asking for a blank check. Changing the definition of interoperability
seems pretty serious. It looks like a subject for a 2026 successor
produced by a WG, not a rider on Brian's extensions draft.

> I don't see how to do that as an

Yeah, there are lots of issues like that.

-- 

Robert Sayre

---

From: Keith Moore <[email-masked]>
Date: Wed, 06 Sep 2006 11:35:40 -0400

> need to know or care about the lower level.

Disagree.  HTTP proxies do exist but the only reason that they can work 
effectively is that the vast majority of web resources are accessible 
through a common medium - namely the public IPv4 Internet and TCP.  If 
the web were split across several networks with dissimilar 
characteristics, it would be much more difficult to arrange seamless 
access via proxies.

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 6 Sep 2006 12:09:48 -0400

On 9/6/06, Keith Moore <[email-masked]> wrote:
>
> HTTP proxies do exist but the only reason that they can work
> through a common medium - namely the public IPv4 Internet and TCP.

Right. But that is a natural occurrence, not the result of
bureaucratic demands for coordination. SMTP doesn't /require/ TCP
either, as I'm sure you know. I don't see a correlation between
protocol effectiveness and concrete transport protocol dependencies. I
also don't see a correlation between mandated "universal"
interoperability and protocol effectiveness.

Application protocols don't need to specify an entire protocol stack
to be successful.

-- 

Robert Sayre

---

From: Jefsey_Morfin <[email-masked]>
Date: Wed, 06 Sep 2006 19:16:36 +0200

At 15:30 06/09/2006, Sam Hartman wrote:
>think we understand how to engineer a network like that today and

Dear Sam,
the error you make is "how to engineer". This were the Harald's RFC 
3935 error is. The world is not engineered. It is by itself. What you 
engineer are ways to make the best of it.

>them.

Don't confuse me. I do not say that Harald wants to design the 
Internet one way or another or that there is an Harald's wrong 
internet. But that he thinks that the Internet can be engineered. RFC 
3935 is about the mission of the IETF. The error is "the IESG is to 
influence the way people design, use and manage the Internet". All 
the rest is fine. The problem is in the confusion about what he calls 
the Internet.

For thousands of years we believed in Ptolemee's model. It gave a lot 
of rewards, including the correct distance between the earth and sun. 
And many roosters that beleived they rose the sun every morning, in 
different religions, stories, etc.

It is just that by essence a model cannot scale.

>We try to be moderately ecologically focused in our thinking.

:-) yes in a pragmatic way. Not in a cartesian way. You make things 
extensible (so you have scalability limits). I try to make them 
intelligible (to understand the nature of the solution when the same 
problem diversify somewhere else). Induction and deduction.

>specific real-world problems.

I am afraid this is exactly the opposite.
I will tell you a simple think: I make my personal living for 20 
years this year of that too forward thinking. I agree that it is not 
that easy as I five years in advance on the market and the market is 
5 years late on itself. But we are now at a time where we could sell 
for $ 250 at the supermarket what I sold $ 250.000 to Monopolies. 
Look at the last ASUS wifi box.

 From my point of view you are accumulating unnecessary problems. We 
are in real world, so we are to process by abduction. Not by 
decision. Eïstein produced a formula, he did not decide the way 
energy should behave from now on.

>Let's take your language tags work.  If
>seriously.

For you to steal it?
Actually I loyally starded and was rebuked. So, ...
Addison Phillips phrased it in a simpler way: come with a solution 
and that the better win (not much a standardisation attitude). Coming 
with one solution when we belong to an emerging industry they want to 
strangle. We just wanted them not to win. And we succeeded.
:-)
I am in competition with Unicode. You do not want to accept it, but 
they do know it. They use the IESG to impose something blocking their 
competition, of which I am a small part. As probably the most R&D 
advanced and the quickest to respond being a light structure, I was 
the one who volunteered when I understood what some others were ready 
to undertake. Our competition want to make billions on our prospects 
and spoil our whole economy.

This is where the layer violation is. You are at "application" layer, 
I am at "architectural" layer. In wanting to mix them, you are 
building castles on the sand. Let understand this first, then let 
find where there is rock, then build an interoperable distributed 
system with deep foundations.

This is why the Internet is blocked. RFC 1958 is great but it is a 
recipe book. We dearly miss a model to support development whatever 
it can be (NGN, GENI, etc.). Not an invented or decided model of the 
Internet. An observed model of the real world digital ecosystem. I 
use and keep validating one for 22 years. It suits me. Work out your 
own, I am sure you can. Then we can talk.

The problem with the langtags was that WG-LTRU missed an IAB RFC to 
provide them with architectural guidance (like in the OPES case), and 
that they even refused to consider their own charter. And the 
implications of what was missing meant.

So they developped a small application. Good. Claiming it was 
univesal, only introduces confusion.

>But as your problem was presented, it was very much a pure research 
>problem not an engineering problem.

You can qualify it the way you want. All I know it is in tune with 
standardizers, users, politics, our needs, and demand wherever I go. 
But I agree their degree of maturity is not the degree of maturity 
of  the intended proposition of the "stakeholders" (cf. RFC 3869).

>This is the IETF not the IRTF and so we will make the valid 
>engineering decision to limit complexity rather than enable research.

Let put it another simple way. You use engineering to impose 
commercial decisions which seem reasonable for your evaluation of 
your market stable corporate oriented economy. And ... I do the same. 
The difference is that my market is more diversified and my economy 
has a different user centric stability algorithm. I only expect from 
it a technological advance. Not sure I why I should give it away :-)

Now, please note that (too keep with the langtag example), IESG look 
IRTF to me. In october alone I have three major "how to" meetings. 
RFC 3066 Bis would be OK, should the IESG respect it. Brian had said 
the ltru-matching would be answered quickly, and I hope it is as well 
answered as the RFC 3066 Bis appeal. This would conclude this 
harassing saga: it was not in order to convince Unicode of anything, 
but to avoid they use the IETF and the IANA against us.

The IETF should not be the place for that kind of strategic 
conflicts. Once the IESG respects RFC 3066 Bis, we will all be able 
to forget the attempt and to patch the interoperability issues.

This being said, your problem today is the intrinsic nature of 
interoperability scaling engineering. To come with a clear and simple 
definition of it is a sine qua non condition for the Internet to 
develop. I am quite glad you eventually rose the issue with Brian. As 
long as the Internet stays with its 1984 DNS, its 1983 IPv4, and its 
interoperability problems with the InterNAT we will not be able to 
progress in common.

What is the external interoperability of the mono-Internet or what is 
the extended nature of the internal interoperability of the 
Multi-Internet? I do not have any engineering problem with that. But 
as John Klensin explained to Todd, my solution is my decision not a 
concerted standard.

Cheers.
jfc

---

From: Jefsey_Morfin <[email-masked]>
Date: Wed, 06 Sep 2006 18:39:31 +0200

At 17:35 06/09/2006, Keith Moore wrote:
>If the web were split across several networks with dissimilar 

The "if" is the reality. Forgetting about it does simplifies things. 
This is like computing the trajectory of a rocket in using scientif 
formulas without corrections. Simpler, but you miss the target.

Ask the Chinese people if it was as seamless for them as for you to 
access the Internet in your mother tongue. Now it is, because they 
split their extenet from yours, in a way which works and hurts no 
one. But it was more difficult. What is poor is that such a way 
should have been first documented by the IETF, based upon an IAB 
guidance. So we could have an optimal, or common solution. Like in 
the HTTP.1.1 case.
jfc

---

From: Jefsey_Morfin <[email-masked]>
Date: Wed, 06 Sep 2006 19:16:36 +0200

Dear Sam,

For you to steal it?

Cheers.
jfc

---

From: Jefsey_Morfin <[email-masked]>
Date: Wed, 06 Sep 2006 18:39:31 +0200

---

From: Keith Moore <[email-masked]>
Date: Wed, 6 Sep 2006 14:44:28 -0400

> bureaucratic demands for coordination. 

It doesn't matter how the conditions came about.  It's rather
arbitrary to say that a protocol cannot require TCP but it can require
message headers to be in a particular format.  The protocol spec
should outline a set of sufficient conditions for interoperability AND
market acceptance.  Providing too many ways of running a protocol
harms interoperability in various ways - not just by providing ways by
which two protocol engines can't talk to one another, but also by
introducing more states in which things can fail.

> SMTP doesn't /require/ TCP
> either, as I'm sure you know.

No.  But exchanging email between administrative domains without explicit
coordination generally _does_ require both TCP and IPv4.

Of course it's useful to be able to run SMTP, HTTP, etc. over other
transports for special purposes.  But a distinction needs to be made
between "SMTP specification" and "how to send Internet email", and
between "HTTP specification" and "how to make web resources available
to the public and how to access them".  In both cases the latter
imposes more necessary conditions than the former.

> I don't see a correlation between protocol effectiveness and
> concrete transport protocol dependencies. I also don't see a
> correlation between mandated "universal" interoperability and
> protocol effectiveness.

It depends on the protocol and the use cases for that protocol.  I've
found it useful in the past, for instance, to run the lpd protocol
over DECnet.  But by doing so I wasn't trying to give our VMS users
access to printers across the globe, just to our local printers.

> Application protocols don't need to specify an entire protocol stack

That doesn't stand as a general statement.  Sometimes they do, because
there are too many possible choices and in the absence of a complete
specification there will never be a critical mass sufficient to
facilitate interoperability.  Sometimes they don't have to explicitly
specify the entire stack, but because there are obvious defaults for
the unspecified portions of the stack, interoperability happens
anyway.  

Some applications (e.g. ssh) are inherently two-party and/or tend to
be used only within local networks, and for these cases all that
really matters is that both ends can agree on a protocol stack and
there is a signal path between them that can run that protocol.
However the utility of many applications is dependent on there being
a large number of servers that arbitrary clients can talk to, and in
those cases too many degrees of freedom regarding which stack to use
degrades interoperability.

Keith

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 6 Sep 2006 14:55:41 -0400

On 9/6/06, Keith Moore <[email-masked]> wrote:
> to the public and how to access them".

I don't think we disagree, and both specs say "usually over TCP" anyway.

> degrades interoperability.

The IETF doesn't have the ability to remove any degrees of freedom.
The IETF can increase the number of dependencies to the point that
there will be lots HTTP-Over-Foo specs, and lots of duplication (and
variation in non-transport areas). The IETF can also provide
compelling solutions like TCP/IP so that most implementers never
consider anything else.

I suppose I would phrase "too many degrees of freedom" as "nothing but
poor standards". Provide an adequate solution that's simple enough to
be ubiquitous and you get critical mass.

-- 

Robert Sayre