Browser IDN display policy: opinions sought

[JFC Morfin]

I am responding to Vint and Martin in the same mail because the
response proceeds from the same idea. Gervase is outside of the IETF
scope: why and hence what is the border of that scope and its implications.

IESG and IAB have clearly explained that the points discussed by my
2010 appeals were outside of their scope. This is why the BoF that
they proposed for me to engage was inappropriate. This is also why I
relied on the IAB roadmap for them to sort out their own definition of
the upper-border of their area. I needed before I would engage in the
documentation of the scope of the communication stratum above, what I
call the semiotic and the semantic layers of the Intersem extending
the OSI communication model to intercomprehension.

At 08:38 12/12/2011, Vint Cerf wrote:
>as ugly as it might be, I wonder whether showing both UNICODE and
>PUNYCODE expressions would be useful? By itself, this might not reveal
>a spoof unless one had bookmarked domain names against which to
>compare, of course. If the viewer does not have an appropriate
>font/script, of course, then only the PUNYCODE is displayable to any
>useful effect. Again, one would need reference points to detect a
>spoof.

Vint,

In "IUser" the "I" stands for many things: IETF, International,
Intelligent, Intertechnology, Internet+, etc. and "lead" (as in "lead
user"), but *not* for the Internet as such (and absolutely not for
ICANN), because it may not be the only infrastructural system
(infrasystem) being used to support their relational space.

Gervase's concerns are "located" outside the Internet, at a layer
where human brains (people) and end-applications (process) belong and
relate through his smart window (browser). His context is, therefore,
the bridge of the person's "cybship" (i.e. the personal digital
continuity that he/she builds and governs, where he/she is
authoritative in the way that he/she uses it and interconnects it to
establish and maintain his/her relations.

-  At the hardware stratum, the cybship will be made of clouds,
servers, PCs, laptops, tablets, mobiles, telemates, appliances,
nanoimplants, browthers, etc. with ultimately at the core and  in
central remote control.  his/her own neurons.

-  At the software stratum, everything may be either binary or
localized. This is the IETF stratum.

-  At the brainware stratum, English may not be the language, may
not be understood and may not be even readable. This means that one
has to accept that ASCII may not belong to personal environments and
that punycode strings may be as foreign to users as ASCII domain
names. This is "above the IETF stratum", IAB/IESG said it is research.
As a consequence, how the IETF stratum is to better support that
"above" is IETF research.

This is why we have to scale from "internationalization", as in Mark
Davis' "globalization", (i.e. quoting localized non-English texts into
International English), to "multilingualisation", i.e. to use Mark's
terms, in localizing internationalization.

Multilingualisation then has to be understood as the cybernetics of
the linguistic diversity, where English is to be accepted as one of
the 22,500 technically strictly equal linguistic entities and Latin
charset as one of 100 technically strictly equal charsets. English and
ASCII may be absent from the user's device. What Gervase asks for is
how his smart windows should display this multilingualisation as far
as IDNs are involved.

OSI wise, the response is with the Internet multilingual layer number
seven service, not with the internationalized internet, which is a way
to name a part of the Internet number six presentation layer. IDNA2008
documents the Internet layer six and the subsidiary support of its
corresponding level seven services on the user side.


At 08:10 12/12/2011, Martin J. Dürst wrote:
>I very much think it is correct. From their very timid start with
>IDNs, ICANN has a strong and confusing tendency to cast issues in
>terms of "language" even if they are script issues. That has
>influenced the surroundings, too.


Martin,

We (IETF) have shared that confusion, e.g. the way we initially
approached langtags, and the fuss that I had to create to obtain a non
destructive langtag RFC set. I acknowledge that there was an effort to
progressively teach the IETF people (not externally) that the language
layer was not appropriate. This led to John Klensin's (quite briefly
at first) conclusion that scripting was the upper concern of the IETF
and that languages were outside of the IETF scope.

This was a great technical clarification progress. However, this did
not free the IETF from Unicode. To the contrary, it gave the illusion
to the IETF that its technical upper border was the same as the
Unicode one (so Unicode and IETF could be bound together).

This is incorrect on at least three points that both IUse and ICANN
had to live with:

a. Unicode version changes that might result from cultural change or
deeper Unicode knowledge.

b. Mapping, an issue that IDNA2008 was set to get rid of and achieved,
but that left unanswered issues and as a result some Unicode
legitimate objections.

c. Lack of orthotypographical (scripting syntax) considerations.

The solutions:

1. Patrik came up with a solution to (a). It seems to be stable enough.


2. Paul and Pete came up with a perspective that permitted a consensus
on (b). However only described by way of an example, the introduced
general solution is subsidiarity: persons do locally what they
authoritatively want as long as their fringe to fringe Internet+
solution respects the end to end Internet requirements.

This calls for an IUI to support a fringe2fringe IUse of the Internet,
i.e. an Internet+ architecture. Limited/initial phase IUI examples are:

o  the Google+ architecture (that we implemented in the Tymnet
technology as the "menuserver" 25 years ago).

o  browsers in the HTTP area. Since there are five major browser
manufacturers, Gervase requests quidance for one of them, and if
possible concertation for them all.


3. The solution to (c) is more complex. It is approached by ICANN as
"variant support". It calls for metadata to be previously known or for
them to be transmitted in parallel. The paradigmatic (typical example)
need is the support of the "majuscule" metadata. This clearly shows
the different responsibility grades between the Unicode, IETF, and IUse areas.

o  if I am correct, Unicode wished to remove the capacity for its
codes to escape to metadata. I think this is correct, and clearly
identifies their character oriented plane, where Unicode/ISO 10646 are
free to correlate with other encodings.

o  the IETF refused to consider orthotypography. I first opposed that
disinterest but I must acknowledge that if this disinterest leaves
only one solution, it seems architecturally the best one: to include
that respective support as a transparently added feature of punycode.
What I call punyplus.


Punycode/Punyplus is, therefore, within the IETF scope. This clearly
shows that it is not a matter for applications and browsers.

The same, anti-phishing and logo/symbol support are not IETF or
Unicode issues but rather IUse issues, through possibly an
anti-phishing algorithm on top of Unicode.


At 07:54 12/12/2011, Martin J. Dürst wrote:
>Yes indeed. The browser vendors overreacted on issues such as
>script-mixing, stuff that the user isn't able to read, and so on,
>because overreacting was easier than a more careful reaction, and they
>were able to say that they did something.

I am afraid that they do not overreact, but rather react to a lack of
the IETF, which was the reason for my appeals. The IDNA RFC set should
have included an IAB disclaimer (as the one they spelled out in their
response) warning that, IDNA2008 made the IETF/Internet community
trespass its own top border, that RFC 5895 was a cross border
involvement (RFC 5895), and how/where to discuss the cross and over
border issues.


>But they didn't do much for in-script attacks, because that's much
>more difficult. (Not that I'm advocating a browser that shows
>MlCR0S0FT.com with punycode.)

Correct, but this is not "they" as in "browser vendors" (actually
"manufacturers") but as in IUsers. Therefore, this is my fault because
I am advocating the IUTF (Intelligent Use Task Force) to emerge and
take over responsibility. Russ Housley carried the IETF role correctly
in creating the iucg at ietf.org mailing list, allowing the emerging IUse
community to liaise with the IETF. However, it has low traffic, not
only because Jefsey the Troll is facilitating it, because it is young,
but also because:

o   the IUse working methods, purpose, deliverables/confusables, and
people dedication are not to be the same as the IETF, in the same way
as ITU methods are not those of the IETF.

o   and mostly because we still have to discover them (and this is
really a very deep discovery process if we want to reach consistency
with world simplicity (RFC 3439) and human noetics (semantic
intercomprehension process.

The only thing I know is that the emerging IUTF will be a place for
browser manufacturers and other W3C web applications plane interests,
but, by far, not only for them.

This is because they are "only" involved in a part of the HTTP
protocol fall outs. The Internet is about TCP/IP: there are other
technologies, and people (as the ultimate target) are interested (cf.
above) in semantic intercomprehension. As an SDO, we are interested in
facilitating that intercomprehension through relational digital tools.

The point here is to understand how to better facilitate it through
the IETF environment stratum (this is actually "making the Internet
work better") in cooperation or not with the fringe to fringe IUI
layers. We see the need confirmed by what we did not specify and what
Gervase requests. We acknowledged its structural existence through the
RFC 5895. However,

o   we have not yet accepted its implications on the IDNA and the
whole Internet architecture.

o   therefore, we did not work and complete yet a list of its
requirements from an Internet point of view (IAB roadmap).

o   and as a result, we did not motivate ICANN and others to seriously
consider all the resulting consequences;


This is why I stated that I will try to complete an IUI Internet
conformant framework description before:

o   ICANN economically and politically settles the technical confusion.

o   in being paid to accept studying requests of IDNgTLDs that it has
absolutely no technical capacity, legal right and, therefore,
political legitimacy to discuss and contract.


Most will certainly dispute my description but my hope is that this
will engage the debate that Lisa Dussault wanted, but which was not in
our charter. My targetsare:

  o   the completion of the first post-IDNA2008 phase (what I called
IDNA2010, i.e. how to use IDNA2008 on the user side) that we need to
achieve before

  o   engaging in the second phase (what I called IDNA2012 - I was
optimistic! - i.e. the way we adapt the Internet stratum to fully
support IDNA2010 [punyplus, IANA, PRECIS, RFC 3935bis, langtags, net
centricity documentation, externets, IP/ID/GRIDv6 consequences,
general lessons on Internet+ architecture, etc.])

  o   while the IUTF (starting through the iucg at ietf.org liaison) will
consider the resulting needs and opportunities (ML-DNS, anti-phishing
algorithm, cybship operance, semiotic implications, distributed root
and IANA, etc.)

  (NB. I know that I use terms that are new for some: they will be
explained in the iucg-internet-plus I_D).

  jfc