[ih] principles of the internet

[John Day]

Are you talking about principles in the formal 
sense, i.e. deriving from fundamentals, or more 
in the folklore sense, i.e. those contributing to 
myth?  I presume the latter.

Strictly speaking, your definition of symmetry is 
correct.  The other way to put it is that the 
protocol machines on either end of the flow are 
the same.  I commiserate with Dave's tale of dumb 
conformance testers.  I have seen them myself. 
However, I would disagree with him that all 
application protocols must be asymmetrical. 
While it represents the majority of those done so 
far, I would also contend that our applications 
so far are pretty rudimentary.  I think the 
Telnet example is quite exemplary.  The vast 
majority of that type of protocol at the time 
were asymmetrical.  Their designers lacked the 
insight to see it as a symmetrical problem.  Most 
thought that it was a terminal to host protocol 
or a remote login protocol (some textbooks still 
describe Telnet that way), when in fact it is a 
device driver protocol.  But then these points 
are moot since there is really only one 
application protocol required anyway.  The 
variety was just an indication of our lack of 
understanding at the time.

The economic issue is a good one.  I always point 
to the failure of the early NETRJE as an example 
of the obvious (elegant) solution being wrong for 
economic reasons.

It is the case that once an asymmetrical protocol 
is introduced into an architecture, it makes very 
difficult to build anything on top of it.

The running code/rough consensus is probably one 
of the more important aspects of driving the 
Internet to a artisan tradition rather than a 
more scientific one.  This is has probably 
contributed most to the stagnation we currently 
see.

An odd complement to the aversion to complexity, 
there seems to be an aversion to sophistication 
that leads to greater simplicity.

The other phenomena which I have noticed but not 
been able to explain was that if one group did X 
(and didn't quite do it right), the Internet 
would do "not X" rather than "let us show you how 
to get that right."

It might be worthwhile to distinguish those 
principles that pre-dated the Internet itself vs 
those that were developed in the various 
precursors and were or were not taken up by the 
Internet

Take care,
John

At 17:47 +0200 2010/06/01, Matthias Bärwolff wrote:
>Dave, thanks for your response.
>
>On 06/01/2010 05:33 PM, Dave Crocker wrote:
>>
>>>  4. cascadability and symmetry (speaking to the rules of efficient and
>>>  flexible protocol design)
>>
>>  What do you mean by the term "cascadability"?  What do you mean by
>>  "symmetry" in this context.
>>
>
>There are ways in which you can have protocols doing similar things
>(e.g. file transfer) but which are not possible to concatenate (or
>cascade) without violating their semantics (pertaining to
>acknowledgments and other such control actions).
>
>Symmetry just means that neither end is conceptually master or slave,
>instead both being equal peers (cf. Telnet symmetry).
>
>>
>>>  5. running code, complexity avoidance, rough consensus, and path
>>>  dependence (speaking to the governance process and its stability)
>>
>>  This sub-list merges at least two very different areas of concern.  One
>>  is the process for developing specification and the other pertains to
>>  technical characteristics of specifications.  The latter is also
>>  reflected elsewhere in your list.
>
>Agreed, the latter stands out somewhat. As for the separation you
>mention, I would think, though, that the feasibility of getting anywhere
>involves both the organization of the process, and the characteristics
>of the resultant artifacts. I will have to think more about this.
>
>Matthias
>
>>
>>  d/
>
>--
>Matthias Bärwolff
>www.bärwolff.de