Subject: [iucg] The point of view of an Internet and IETF deliverables user

From: jefsey <[email-masked]>
Date: Mon, 08 Mar 2010 08:01:15 +0100

Hi!
I would be interested by comments (on this list or private, French or 
English) on this text regarding the point of view we may have 
regarding IDNA2008.
Thank you for your cooperation.
jfc

The point of view of an Internet and IETF deliverables user

I am a person.

This means that I am centric to the information society. This also 
technically means that I am a subject operated by a natural semantic 
processor of the HSS brand (Homo Sapiens Sapiens) whose capacities 
interact with material and immaterial objects and semiotically 
relates with other subjects throughout various ecosystems. For 
example, my body is my interface with the physical ecosystem; it 
supports my semiophysical capabilities (utterances, gestures, etc.) 
that include my semiodigital abilities (use of a computer, mobile 
phone, word processor, mouse, etc.).

I am an Internet user.

This means that one of these ecosystems that I belong to is the world 
digital ecosystem (WDE) of which the Internet is the current main 
content level communication commodity. My digital self is, therefore, 
embodied in my "cybship", i.e. the real and virtual elements that are 
necessary to my online presence and all the various online properties 
and systems of mine that I may use to navigate and operate in my digital life.

I am an Internet lead user.

This means that I am interested in improving my own digital semiotic 
capacities and the semiotic and behavioral feedback of those of whom 
I use to interact and relate. This implies:
·         the best adminance of my, and of the common, investments,
·         the best governance of my, and of the common, digital and 
general life,
·        their most pertinent concertation (usa: concerted cooperation).

This memo only focuses on the adminance part, i.e. how to provide 
governance with the structural tools that it needs for all of us to 
best use them.

The adminance of my, and of the common, structural tools calls for 
stability and the enhancement of what exists:
·         Stability can be ensured by way of the maintenance of 
equipment and the governance of its rules of use.
·         Enhancement results from structural investment innovation.

Innovation can be inventive, incremental, disruptive, or architectural.

o   Inventive innovation is usually academic.
o   Incremental innovation in the signal and content communication 
areas primarily belongs to the ITU and IETF scopes.
o   Disruptive innovation usually spurs industrial ventures.

o   Architectural innovation is often a synonym for complexity 
simplification, something that often results from looking at an 
established solution set within a new user perspective.

If I consider the current state of my communication capabilities, I 
can clearly see that I am "half-way through":
·         Signal and passive content bandwidth and communications are 
available with half the world being connected (Internet, mobile 
phones) under stable terms, which might be endangered by some 
political and commercial interests.
·         ambient and active content and semantic bandwidth and 
communications are not available yet.

I can actually perceive an intrinsic architectural difference between 
what I already have and what I am missing.

·         What I have supports me, as in any other end user, among 
the growing billions of accessing interchangeable other people or 
machines, while only being identified through a stable or transient 
IP address. This unique neutrally shared system works well, but it 
has a growth problem that is leading to concerns about its most 
precious feature: neutrality. This is a system matching end to end 
diversity by growth.
·         What I am missing will have to successfully support me as a 
particular interuser, who is calling and being called because he or 
she is unique throughout the diversity of the billions of interusers. 
The question is then: could such a multiplicity work? This would be a 
system addressing diversity by multiplication.

Up to now, Internet technology seems to have supported multiplication 
(charsets, IP addresses, number of accesses, traffic, root servers, 
etc. ) by growth. This has been documented in four occurrences, in 
particular: RFC 1958, RFC 3439, RFC 3935 and US and French laws, and IDNA2003.

1.       RFC 1958 is based upon the permanent change principle 
("Principles that seem sacred today will be deprecated tomorrow. The 
principle of constant change is perhaps the only principle of the 
Internet that should survive indefinitely"), and on the guidelines 
that should, therefore, be revisited upon experience but that seem to 
remain rather pertinent:

·         The goal is connectivity, the tool is the Internet 
Protocol, and the intelligence is end to end rather than hidden in the network.
·         Connectivity is its own reward.
·         In an ideal situation there should be one, and only one, 
protocol at the Internet level.
·         End-to-end functions can best be realized by end-to-end protocols.
·         Everything else should be done at the fringes.
·         Nobody owns the Internet, there is no centralized control.
·         Heterogeneity is inevitable and must be supported by design.
·         If there are several ways of doing the same thing, choose one.
·         All designs must scale readily to very many nodes per site 
and to many millions of sites.
·         Performance and cost must be considered as well as functionality.
·         Keep it simple. When in doubt during design, choose the 
simplest solution.
·         Modularity is good. If you can keep things separate, do so.
·         In many cases it is better to adopt an almost complete 
solution now, rather than to wait until a perfect solution can be found.
·         Avoid options and parameters whenever possible.  Any 
options and parameters should be configured or negotiated dynamically 
rather than manually.
·         Be strict when sending and tolerant when receiving.
·         Be parsimonious with unsolicited packets, especially 
multicasts and broadcasts.
·         Circular dependencies must be avoided.
·         Objects should be self describing (include type and size), 
within reasonable limits.
·         All specifications should use the same terminology and 
notation, and the same bit- and byte-order convention
·         Nothing gets standardized until there are multiple 
instances of running code.
·         Avoid any design that requires addresses to be hard coded.
·         A single naming structure should be used.
·         Public (i.e. widely visible) names should be in 
case-independent ASCII.  Specifically, this refers to DNS names.
·         Addresses must be unambiguous (unique within any scope 
where they may appear).
·         Upper layer protocols must be able to identify end-points 
unambiguously.
·         Prefer unpatented technology.
·         Any implementation which does not include all of the 
required components cannot claim conformance with the standard.
·         Designs should be fully international, with support for 
localisation (adaptation to local character sets).
·         All designs must fit into the IP security architecture.
·         Confidentiality and authentication are the responsibility 
of end users and must be implemented in the protocols used by the end users.
·         Wherever an algorithm is called for in a protocol, the 
protocol should be designed to permit alternative algorithms to be 
used and the specific algorithm employed in a particular 
implementation should be explicitly labeled.
·         Preference should be given to algorithms which have stood 
the test of time and which are not unnecessarily inefficient.
·         To ensure interoperation between endpoints making use of 
security services, one algorithm (or suite of algorithms) should be 
mandated to ensure the ability to negotiate a secure context between 
implementations.

2.       RFC 3439 documents the Internet as a very large system 
calling for an absolute respect of the Simplicity Principle, which 
states that complexity is the primary mechanism that impedes 
efficient scaling. This directly matches our lead user architectural 
primary concern: simplifying complexity rather than incrementally 
addressing it or disruptively increasing it.

However, if RFC 3439:

·         does explains that "optimization can also be considered 
harmful. [as it] introduces complexity, [as it introduces ] 
introducing tighter coupling between components and layers" because 
"much of the non-linearity observed [in] large systems is largely due 
to coupling."

·         it does not propose any simplification doctrine based on 
uncoupling. However, it seems to introduce one when it notes that: 
"Adding a new Internet service is just a matter of distributing an 
application to a few consenting desktops who wish to use it."

3.       RFC 3935 perceives the Internet of Engineers as:

a large, heterogeneous collection of interconnected core and edge 
systems that can be used for communication of many different types 
between any interested parties connected to it. The Internet is a 
truly global network, reaching into just about every country in the world.

which can be matched with the legal operators perception of:
a combination of computer facilities and electromagnetic transmission 
media, and related equipment and software, comprising the 
interconnected worldwide network of computer networks that employ the 
Transmission Control Protocol/Internet Protocol or any successor 
protocol to transmit information.

and the user perception of "online" services based, by French law, on trust.

A convergent open definition could then be:

all the packet-switched interconnected processors to support trusted 
public and private online communications and relational services.

4.       the widest diversity that the Internet has had to meet up to 
now is the linguistic diversity (there are around 25,000 
sociolinguistic units and languages and IP evolve all the time). Such 
diversity is addressed in network architectures by the presentation 
layer. IETF, so far, has documented no presentation layer support for 
the Internet. The linguistic diversity has, therefore, been met by 
increasing the character bandwidth (ISO 10646 - Unicode, which now 
supports nearly 100,000 signs), this is usually called i18n, or 
internationalization.

A user can be offered five main levels of support for linguistic diversity:

·         none

Linguistic issues are not considered by technology. This may result 
from the use of signs, numbers, keys, or nothing like a physical voice.

·         lingualization

A given natural or coded language is at some stage embedded in the 
technology. Plurilingualization is possible by using polynyms 
(synonyms in different languages).

The Internet is lingualized (RFC 3935: The "IETF uses the English 
language for its work [] because of its utility for working in a 
global context.").

·         globalization

A lingualized technology is extended in order to be able to 
transparently quote any other language.

This calls for at least three features:
o   support of the typography that is used by every language. This is 
internationalization. Every existing character should be supported 
end to end by the medium.
o   support of the cultural orthotypography (or typographical syntax: 
what defines the meaning and rightful usage of typographic signs, 
formats, etc.). This is "localization". Computer localization is 
documented in "locale" files.
o   content tagging in order to indicate the orthotypographic 
conventions of the source. This is the RFC 4645, 5646, and 4647 set.

·         multilingualization

This means that the technology in turn supports the human 
orthotypography. This is necessary for any semantic oriented services.

·         universalization

At this level, sememes (semantic units) are used. They are 
externalized through the mecasemiotic or mecalanguage (sememes 
driven, machine semiotic or natural language versions) of each end.

IDNA2003 in being tightly coupled to Unicode and its machine level 
orthotypography (CLDR project) was rigidly bound to an end to end 
globalization. Together with the IANA langtags registry, this 
provided users with a consistent experience of the globalized 
Internet system, fully supporting the various diversities (speed, 
protocols, addresses, traffic types, machines typography and 
orthotypography, languages, etc.) through single corresponding bandwidths.

IDNA2008 does not change that Internet. To the contrary, because it 
rightly acknowledges that my semantically driven orthotypographic 
needs are too complex for a single end to end solution, it proposes 
to use that globalized Internet as a rock solid, end to end, LDH DNS, 
intelligence on the fringes, digitally globalized, etc. core 
tool-kit, together with its RFC 1958/3439 checklists, in turn 
allowing us, interusers, to build our own Internet usage Interface 
(IUI) and our own IUI to IUI conventions.

Multiplication no longer has to be supported by bandwidth growth (in 
this case typographic and orthotypographic bandwidth), but is 
distributed among the myriad of our user processors. It is up to us 
to support our human semantic inter-relational protocols, that is to 
say natural languages.

This acknowledges the RFC 3439 Law of Diminishing Returns, which 
states that if one factor of production is increased while the others 
remain constant (such as some mapping at the protocol level, i.e. 
within the Internet core), the overall returns will relatively 
decrease after a certain point (IDNA general usability). IDNA2008, in 
uncoupling IDNA from Unicode versions, acknowledges that "trying to 
squeeze out" Unicode efficiency in core Internet protocols "past" the 
ASCII DNS "only adds complexity, and hence leads to less reliable systems".

In addition, brain to brain interintelligibility proceeds from a 
non-binary simplicity. It became too complex to support it in using 
global protocols past the passive content layer. The elegance of 
IDNA2008 is to use the Unicode based punycode algorithm to build an 
hourglass solution where the entire multilingual name space is 
robustly and flexibly supported by multiplication at the IUI to IUI 
layer, over protected end to end legacy ASCII DNS.

However, there is a big "however"

This "however" is that a user guide is missing. As an interuser 
having to support my language, I need a user guide to inform me as to 
how to best use the RFC 1958/3439 checklist, at the IUI layer, when 
having to properly and securely interface the Internet IDNA2008 protocol.

As an interuser, I know that there is now an "Internet tool-kit" 
permitting me to engage in my second half-way journey towards the 
brain to brain communications and facilitation services that I strive for:
·         first in supporting extended network services on my 
computer side (we understand):

o   basic services, as transport related,
o   value-added services, as envelope related,
o   and extended ones, as content related.

I expect that these extended services will:

o   not only serve a robust WIRIWIG (what I register is what I get) 
ML-DNS domain name pile (i.e. all the UTF to ASCII various 
presentations of the same domain name) depending on the used 
algorithms and resolution systems.
o   but also support ambient content (for example, local speed limit) 
and active content (what you get is what I wanted you to receive, not 
what I sent).

This is the field of the Interplus proposition - an IUI architecture 
that has the unfortunate capacity to easily support the Internet 
presentation layer as a fall-out of IDNA, the French orthotypography 
that IDNA2008 does not support, the non-administered yet unique DNS 
virtual root matrix with billions of non-necessarily unique TLDs in 
all the classes, and a few other possibilities.

·         then, I will be in a position to enter the semiodigital 
area of the semantic bandwidth and communication, which we call the Intersem.

This is why some concerted guidance and community assistance would be 
of great help.
·         Maybe with an Internet Adminance enhanced cooperation that 
I could trust,
·         certainly with an IDNA usage oriented best practice 
document and forum,

·         and an IUI architectural research on the best IDNA and 
Internet Multiplication capacity matching configuration that I should adopt.

Am I wrong if?...

Am I not better off by having a single Internet Multiplication 
Management System on my PC rather than every application using its 
own solution brand?

For example, I would prefer one single IDNApplication supporting IDNs 
rather than different custom modules in my various browsers, mail agent, etc.

If I feel that I should reconsider my entire "cybship" architecture 
so that it may adapt from sailing in its enlarging river environment 
in order to navigate the varied weather of the multiple 
internationalized high seas.

I would like to first adapt my system terminology in order to be relevant:
·         every system belongs to that system intricacy that the universe is.
·         the part of that universe that may relate with a system is 
its exotem.
·         the interface between a system and its exotem is its peritem.
·         it is subjective as to how one considers a system from its inside.
·         perijective from its peritem.
·         circumjective from it neighborhood.
·         objective from its exotem.

This would mean that:

·         the Internet exotem is every system that may immediately, 
or in the future, relate with the Internet.
·         the Internet peritem should, therefore, be designed so as 
to be interoperable with all of its exotem.
·         by its open definition (communication continuity of the 
universe digital eco-system), the Internet has an unlimited size 
(every processor made interoperable by packet switching networks) 
from nanos to galaxies. In this, it is another "universal", such as 
the cosmos, life, time, etc.
·         henceforth, its exotem necessarily includes the 
"internat(ure)" , the natural ecosystem communication continuity.
·         since we cannot change the natural simplicity, 
interoperability with the "internat" calls for the Internet 
simplicity that is demanded by RFC 3439 to be interoperable with the 
simplicity of the "natural" diversity. This is what the "Mapping" 
document alludes to when it refers to the "unusual" need for the IETF 
to document exotemic particulars in the case of the natural 
linguistic diversity.

At this stage, IAB guidance is needed. RFC 3439 states that the 
Internet, as a very large system, is to be based upon the Simplicity 
Principle, which states that complexity is the primary mechanism that 
impedes efficient scaling. IDNA2008 "unusually" accepts to
·         uncouple the end to end globally unique core network system
·         from the user linguistic diversity semantically controlled exotem
·         introducing a linguistic Internet peritem that is to be 
built by the myriad of users' own linguistic peritems,

·         as a simplification of complexity.

This leads one to think that the "Mapping" document, which was 
necessary to address the IDNA2008 impasse but that the IESG has not 
approved yet, seems to clearly identify:
·         the Internet system to where the IETF can use MUSTs
·         the Internet peritem to where the IETF can use SHOULDs
·         the Internet exotem to where the IETF can only use MAYs

Guidance is, therefore, needed from the IAB in at least two areas:

·         Is the Internet Simplicity Principle's simplicity the same 
as Nature's simplicity (that can be summarized by Maupertuis' 
universally accepted principle). How do they differ? How do they 
interoperate? What are the implications?
·         Does the Internet peritem belong to the IETF scope?

Other guidance that I will need, as an interuser, is to know about 
the reproducibility of the IDNA2008 architectural simplification, 
because there are other areas where "the probability of achieving a 
stable implementation of an architecture is inversely proportional to 
its number of components" (RFC 3439). Moreover, complexity is often 
"software-based, not hardware driven, and therefore had cost curves 
worse than Moore's Law.", which may lead to situations such as ROAP.

In particular, I need to know if the Amplification Principle 
constrains or frees the various IDNA2008 deployment strategies. It 
states that there are non-linearities that occur on a large scale 
that do not occur on a small to medium scale. IDNA2008, as I see it, 
still extends the size of the Internet, and multiplies the number of 
small things. Is this multiplication acting as a catalyst or, to the 
contrary, as an uncoupling inhibitor of their possibly huge impact 
amplification? Furthermore, RFC 3439 states that the minimization of 
interaction contributes to simplicity. It adds: "As a result, 
consideration of "core vs. end-point" state interaction is crucial 
when analyzing protocols such as Network Address Translation (NAT), 
which reduce the transparency between network and hosts.". Will IUIs 
have a NAT like effect or will the strict polynymy (synonymy in 
different languages) of the ML-DNS pile (bijective conversion between 
the various versions of a domain name through its different layers: 
A-label/U-label) protect users from this?

---

From: jean-michel bernier de portzamparc <[email-masked]>
Date: Tue, 9 Mar 2010 04:32:14 +0100

I started to be worried by your silence.

I see that you keep using "stability" as an argument. Should it not be time
to replace (and document why) it by "adaptation and predictability" as we
discussed it from Jeff Hawkins?

I think we could go further and discuss the way it can relate with brain
oriented applications to make understand where we are at.

Otherwise it is a good summary of our discussions. May be remove
"concertation" which is European (we understand the US version).

Un commentaire dans le texte. I will come back to you on this.

Portzamparc

2010/3/8 jefsey <[email-masked]>

> English) on this text regarding the point of view we may have regarding
> IDNA2008.
> *The point of view of an Internet and IETF deliverables user
>
> *
> *I am a person.*
>
> processor of the HSS brand (Homo Sapiens Sapiens) whose capacities interact
> with material and immaterial objects and semiotically relates with other
> subjects throughout various ecosystems. For example, my body is my interface
> with the physical ecosystem; it supports my semiophysical capabilities
> (utterances, gestures, etc.) that include my semiodigital abilities (use of
> a computer, mobile phone, word processor, mouse, etc.).
>
>
> *I am an Internet user.*
>
> digital ecosystem (WDE) of which the Internet is the current main content
> level communication commodity. My digital self is, therefore, embodied in my
> "cybship", i.e. the real and virtual elements that are necessary to my
> online presence and all the various online properties and systems of mine
> that I may use to navigate and operate in my digital life.
>
>
> *I am an Internet lead user.*
>
> capacities and the semiotic and behavioral feedback of those of whom I use
> to interact and relate. This implies:
> ·         the best governance of my, and of the common, digital and general
> life,
> governance with the structural tools that it needs for all of us to best use
> them.
>
> ·         *Stability* can be ensured by way of the maintenance of
> ·         *Enhancement *results from structural investment innovation.
>
> o   Incremental innovation in the signal and content communication areas
> primarily belongs to the ITU and IETF scopes.
> simplification, something that often results from looking at an established
> solution set within a new user perspective.
>
>
> If I consider the current state of my communication capabilities, I can
> clearly see that I am "half-way through":
> ·         *Signal and passive content* bandwidth and communications are
> available with half the world being connected (Internet, mobile phones)
> under stable terms, which might be endangered by some political and
> commercial interests.
> ·         *ambient and active content and semantic* bandwidth and
> I can actually perceive an intrinsic architectural difference between what
> I already have and what I am missing.
>
> ·         What I have supports me, as in any other *end user*, among the
> growing billions of accessing interchangeable other people or machines,
> while only being identified through a stable or transient IP address. This
> unique *neutrally shared* system works well, but it has a growth problem
> that is leading to concerns about its most precious feature: *neutrality*.
> This is a system matching end to end diversity by *growth*.
> particular *interuser*, who is calling and being called because he or she
> is unique throughout the diversity of the billions of interusers. The
> question is then: could such a multiplicity work? This would be a system
> addressing diversity by *multiplication*.
>
>
> (charsets, IP addresses, number of accesses, traffic, root servers, etc. )
> by growth. This has been documented in four occurrences, in particular: RFC
> 1958, RFC 3439, RFC 3935 and US and French laws, and IDNA2003.
>
> 1.       RFC 1958 is based upon the permanent change principle ("Principles
> that seem sacred today will be deprecated tomorrow. The principle of
> constant change is perhaps the only principle of the Internet that should
> survive indefinitely"), and on the guidelines that should, therefore, be
> revisited upon experience but that seem to remain rather pertinent:
>
>
> ·         The goal is connectivity, the tool is the Internet Protocol, and
> the intelligence is end to end rather than hidden in the network.
> ·         In an ideal situation there should be one, and only one, protocol
> at the Internet level.
> ·         All designs must scale readily to very many nodes per site and to
> many millions of sites.
> ·         Keep it simple. When in doubt during design, choose the simplest
> solution.
> ·         In many cases it is better to adopt an almost complete solution
> now, rather than to wait until a perfect solution can be found.
> ·         Avoid options and parameters whenever possible.  Any options and
> parameters should be configured or negotiated dynamically rather than
> manually.
> ·         Be parsimonious with unsolicited packets, especially multicasts
> and broadcasts.
> ·         Objects should be self describing (include type and size), within
> reasonable limits.
> ·         All specifications should use the same terminology and notation,
> and the same bit- and byte-order convention
> ·         Nothing gets standardized until there are multiple instances of
> running code.
> ·         Public (i.e. widely visible) names should be in case-independent
> ASCII.  Specifically, this refers to DNS names.
> ·         Addresses must be unambiguous (unique within any scope where they
> may appear).
> ·         Any implementation which does not include all of the required
> components cannot claim conformance with the standard.
> ·         Confidentiality and authentication are the responsibility of end
> users and must be implemented in the protocols used by the end users.
> ·         Wherever an algorithm is called for in a protocol, the protocol
> should be designed to permit alternative algorithms to be used and the
> specific algorithm employed in a particular implementation should be
> explicitly labeled.
> ·         Preference should be given to algorithms which have stood the
> test of time and which are not unnecessarily inefficient.
> ·         To ensure interoperation between endpoints making use of security
> services, one algorithm (or suite of algorithms) should be mandated to
> ensure the ability to negotiate a secure context between implementations.
>
> 2.       RFC 3439 documents the Internet as a very *large system* calling
> for an absolute respect of the Simplicity Principle, which states that
> complexity is the primary mechanism that impedes efficient scaling. This
> directly matches our lead user architectural primary concern: simplifying
> complexity rather than incrementally addressing it or disruptively
> increasing it.
>
> However, if RFC 3439:
>
> ·         does explains that "optimization can also be considered harmful.
> [as it] introduces complexity, [as it introduces ] introducing tighter
> coupling between components and layers" because "much of the non-linearity
> observed [in] large systems is largely due to coupling."
>
> uncoupling. However, it seems to introduce one when it notes that: "Adding a
> new Internet service is just a matter of distributing an application to a
> few consenting desktops who wish to use it."
>
>
> a large, heterogeneous collection of interconnected core and edge systems
> that can be used for communication of many different types between any
> interested parties connected to it. The Internet is a truly global
> network, reaching into just about every country in the world.
>
>
> *a combination of computer facilities and electromagnetic transmission
> media, and related equipment and software, comprising the interconnected
> worldwide network of computer networks that employ the Transmission Control
> Protocol/Internet Protocol or any successor protocol to transmit
> information.
>
> *and the user perception of "online" services based, by French law, on
> trust.
>
> *all the packet-switched interconnected processors to support trusted
> *

You forget about adjencies. This will make your text less readable for
Asians.Moreover you quote "bandwidth and communications" several times.

> *
>
> *
> 4.       the widest diversity that the Internet has had to meet up to now
> is the linguistic diversity (there are around 25,000 sociolinguistic units
> and languages and IP evolve all the time). Such diversity is addressed in
> network architectures by the presentation layer. IETF, so far, has
> documented no presentation layer support for the Internet. The linguistic
> diversity has, therefore, been met by increasing the character bandwidth
> (ISO 10646 - Unicode, which now supports nearly 100,000 signs), this is
> usually called i18n, or internationalization.
>
> ·         *none
> *
> Linguistic issues are not considered by technology. This may result from
> the use of signs, numbers, keys, or nothing like a physical voice.
>
> ·         *lingualization
> *
> technology. Plurilingualization is possible by using polynyms (synonyms in
> different languages).
>
> The Internet is lingualized (RFC 3935: The "IETF uses the English language
> for its work [] because of its utility for working in a global context.").
>
> ·         *globalization
> *
> A lingualized technology is extended in order to be able to transparently
> quote any other language.
>
> o   support of the *typography *that is* *used by every language. This is
> *internationalization*. Every existing character should be supported end
> to end by the medium.
> o   support of the cultural* orthotypography* (or typographical syntax:
> what defines the meaning and rightful usage of typographic signs, formats,
> etc.). This is "*localization*". Computer localization is documented in
> "locale" files.
> o   *content tagging* in order to indicate the *orthotypographic
> conventions* of the source. This is the RFC 4645, 5646, and 4647 set.
>
> ·         *multilingualization
> *
> This means that the technology in turn supports the human orthotypography.
> This is necessary for any semantic oriented services.
>
> ·         *universalization
> *
> At this level, sememes (semantic units) are used. They are externalized
> through the mecasemiotic or mecalanguage (sememes driven, machine semiotic
> or natural language versions) of each end.
>
>
> globalization. Together with the IANA langtags registry, this provided users
> with a consistent experience of the globalized Internet system, fully
> supporting the various diversities (speed, protocols, addresses, traffic
> types, machines typography and orthotypography, languages, etc.) through
> single corresponding bandwidths.
>
>
>
> IDNA2008 does not change that Internet. To the contrary, because it rightly
> acknowledges that my semantically driven orthotypographic needs are too
> complex for a single end to end solution, it proposes to use that globalized
> Internet as a rock solid, end to end, LDH DNS, intelligence on the fringes,
> digitally globalized, etc. core tool-kit, together with its RFC 1958/3439
> checklists, in turn allowing us, interusers, to build our own *Internet
> usage Interface* (IUI) and our own *IUI to IUI* conventions.
>
> Multiplication no longer has to be supported by bandwidth growth (in this
> case typographic and orthotypographic bandwidth), but is distributed among
> the myriad of our user processors. It is up to us to support our human
> semantic inter-relational protocols, that is to say natural languages.
>
> This acknowledges the RFC 3439 Law of Diminishing Returns, which states
> that if one factor of production is increased while the others remain
> constant (such as some mapping at the protocol level, i.e. within the
> Internet core), the overall returns will relatively decrease after a certain
> point (IDNA general usability). IDNA2008, in uncoupling IDNA from Unicode
> versions, acknowledges that "trying to squeeze out" Unicode efficiency in
> core Internet protocols "past" the ASCII DNS "only adds complexity, and
> hence leads to less reliable systems".
>
>
>
> In addition, brain to brain interintelligibility proceeds from a non-binary
> simplicity. It became too complex to support it in using global protocols
> past the passive content layer. The elegance of IDNA2008 is to use the
> Unicode based punycode algorithm to build an hourglass solution where the
> entire multilingual name space is robustly and flexibly supported by
> multiplication at the IUI to IUI layer, over protected end to end legacy
> ASCII DNS.
>
>
>
> *However, there is a big "however"
>
> *This "however" is that a user guide is missing. As an interuser having to
> support my language, I need a user guide to inform me as to how to best use
> the RFC 1958/3439 checklist, at the IUI layer, when having to properly and
> securely interface the Internet IDNA2008 protocol.
>
>
>
> As an interuser, I know that there is now an "Internet tool-kit" permitting
> me to engage in my second half-way journey towards the brain to brain
> communications and facilitation services that I strive for:
> ·         first in supporting extended network services on my computer side
> (we understand):
>
> o   *basic *services, as transport related,
> o   *value-added* services, as envelope related,
> o   and *extended* ones, as content related.
>
> o   not only serve a robust WIRIWIG (what I register is what I get) ML-DNS
> domain name pile (i.e. all the UTF to ASCII *various presentations of the
> same domain name*) depending on the used algorithms and resolution
> systems.
> o   but also support *ambient *content (for example, local speed limit)
> and *active* content (what you get is what I wanted you to receive, not
> what I sent).
>
> This is the field of the Interplus proposition - an IUI architecture that
> has the unfortunate capacity to easily support the Internet presentation
> layer as a fall-out of IDNA, the French orthotypography that IDNA2008 does
> not support, the non-administered yet unique DNS virtual root matrix with
> billions of non-necessarily unique TLDs in all the classes, and a few other
> possibilities.
>
> ·         then, I will be in a position to enter the semiodigital area of
> the semantic bandwidth and communication, which we call the *Intersem*.
>
>
>
> This is why some concerted guidance and community assistance would be of
> great help.
> ·         Maybe with an Internet Adminance enhanced cooperation that I
> could trust,
> ·         certainly with an IDNA usage oriented best practice document and
> forum,
>
> ·         and an IUI architectural research on the best IDNA and Internet
> Multiplication capacity matching configuration that I should adopt.
>
> *
>
> Am I wrong if?...
>
> *Am I not better off by having a single Internet Multiplication Management
> System on my PC rather than every application using its own solution brand?
>
> If I feel that I should reconsider my entire "cybship" architecture so that
> it may adapt from sailing in its enlarging river environment in order to
> navigate the varied weather of the multiple internationalized high seas.
>
>
>
> ·         the part of that universe that may relate with a system is its
> exotem.
> ·         the Internet exotem is every system that may immediately, or in
> the future, relate with the Internet.
> ·         the Internet peritem should, therefore, be designed so as to be
> interoperable with all of its exotem.
> ·         by its open definition (communication continuity of the universe
> digital eco-system), the Internet has an unlimited size (every processor
> made interoperable by packet switching networks) from nanos to galaxies. In
> this, it is another "universal", such as the cosmos, life, time, etc.
> ·         henceforth, its exotem necessarily includes the "internat(ure)" ,
> the natural ecosystem communication continuity.
> ·         since we cannot change the natural simplicity, interoperability
> with the "internat" calls for the Internet simplicity that is demanded by
> RFC 3439 to be interoperable with the simplicity of the "natural" diversity.
> This is what the "Mapping" document alludes to when it refers to the
> "unusual" need for the IETF to document exotemic particulars in the case of
> the natural linguistic diversity.
>
>
>
> At this stage, IAB guidance is needed. RFC 3439 states that the Internet,
> as a very large system, is to be based upon the Simplicity Principle, which
> states that complexity is the primary mechanism that impedes efficient
> scaling. IDNA2008 "unusually" accepts to
> ·         introducing a linguistic Internet peritem that is to be built by
> the myriad of users' own linguistic peritems,
>
> ·         as a *simplification of complexity*.
>
> This leads one to think that the "Mapping" document, which was necessary to
> address the IDNA2008 impasse but that the IESG has not approved yet, seems
> to clearly identify:
> ·         the Internet *system* to where the IETF can use *MUST*s
> ·         the Internet *peritem* to where the IETF can use *SHOULD*s
> ·         the Internet* exotem* to where the IETF can only use *MAY*s
>
> ·         Is the Internet Simplicity Principle's simplicity the same as
> Nature's simplicity (that can be summarized by Maupertuis' universally
> accepted principle). How do they differ? How do they interoperate? What are
> the implications?
> ·         Does the *Internet peritem* belong to the *IETF scope*?
>
>
>
> Other guidance that I will need, as an interuser, is to know about the
> reproducibility of the IDNA2008 architectural simplification, because there
> are other areas where "the probability of achieving a stable implementation
> of an architecture is inversely proportional to its number of components"
> (RFC 3439). Moreover, complexity is often "software-based, not hardware
> driven, and therefore had cost curves worse than Moore's Law.", which may
> lead to situations such as ROAP.
>
> In particular, I need to know if the Amplification Principle constrains or
> frees the various IDNA2008 deployment strategies. It states that there are
> non-linearities that occur on a large scale that do not occur on a small to
> medium scale. IDNA2008, as I see it, still extends the size of the Internet,
> and multiplies the number of small things. Is this multiplication acting as
> a catalyst or, to the contrary, as an uncoupling inhibitor of their possibly
> huge impact amplification? Furthermore, RFC 3439 states that the
> minimization of interaction contributes to simplicity. It adds: "As a
> result, consideration of "core vs. end-point" state interaction is crucial
> when analyzing protocols such as Network Address Translation (NAT), which
> reduce the transparency between network and hosts.". Will IUIs have a NAT
> like effect or will the strict polynymy (synonymy in different languages) of
> the ML-DNS pile (bijective conversion between the various versions of a
> domain name through its different layers: A-label/U-label) protect users
> from this?
>
>
> _______________________________________________
> iucg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iucg
>
>

---

From: JFC Morfin <[email-masked]>
Date: Tue, 09 Mar 2010 10:27:52 +0100

>I started to be worried by your silence.

Computer crash at the right time :-) !

>I see that you keep using "stability" as an argument. Should it not 
>be time to replace (and document why) it by "adaptation and 
>predictability" as we discussed it from Jeff Hawkins?

Jeff Hawkins has a very eleguant understanding of a large part of the 
brain, but I do not think its propositions belong to the internet. If 
I was to give an analogy I would say that telecoms are to compare to 
material, the current internet to vegetal, the interplus to life and 
the Intersem to mamals. Jeff Hawkins starts being interesting for 
interplus slots. We already do a lot with bayesian networks, having 
an intelligent device integrated in the interbox could help a lot. If 
you think of it it will be like firewalls at the internet level.

>I think we could go further and discuss the way it can relate with 
>brain oriented applications to make understand where we are at.

Look, for the time being we are at trying making clear to the IESG 
that they did the right choice, but we feel that (1) it is a big one 
(2) the Internet cannot be used with a lame IDNA (working well on the 
net side and missing a proprer user side).

>"concertation" which is European (we understand the US version).

OK.

>a combination of computer facilities and electromagnetic 
>transmission media, and related equipment and software, comprising 
>the interconnected worldwide network of computer networks that 
>employ the Transmission Control Protocol/Internet Protocol or any 
>successor protocol to transmit information.
>
>You forget about adjencies. This will make your text less readable 
>for Asians.Moreover you quote "bandwidth and communications" several times.

Looked a lot for this one. I was fooled by the format.

This is good Jeff Hawkins' point if I am right. I am not good enough 
in English: would "interconnecting" processors do the trick (takes 
mobiles, dynamic adjancies, etc. into account)?

jfc

---

From: Marie-France Berny <[email-masked]>
Date: Tue, 9 Mar 2010 11:02:25 +0100

Jefsey,

when you mean "trusted" don't you mean "neutral"? You want something
predictable to be sure you are not fooled. If you do not want to use the
term "predictable" yet, you could use the current buzzword: "neutral" as a
simplified form of predictability ?

Marie-France

PS. I went through your text. Many small points we will discuss at the light
of the IESG answer. May be could you give a better definition of an
"interuser" (I understand both an Internet User and a User who calls and who
is called, and probably an Interplus user/host?)

*all the packet-switched interconnected processors to support trusted public
> and private online communications and relational services.*
> This is good Jeff Hawkins' point if I am right. I am not good enough in
> English: would "interconnecting" processors do the trick (takes mobiles,
> dynamic adjancies, etc. into account)?
>
> jfc
>