<html>
<body>
At 00:15 17/11/2012, Vint Cerf wrote:<br>
<blockquote type=cite class=cite cite="">I am loathe to return to the
debates of the 2008-2010 period but the strong utility of canonical forms
that are unambiguous as to identity (ie between A-Label and U-Label)
should not be underestimated. Mapping has the unfortunate side-effect of
making things "equivalent" when they are not in fact identical.
I think many who were in favor of the IDNA2008 formulation were persuaded
that this powerful feature was worth some breakage with regard to
backward compatibility. It is obvious that there is a value judgment here
and people's opinions varied. <br>
vint</blockquote><br><br>
Anne, <br><br>
As you have noticed, there are still some misunderstandings between two
points of view (WG and Mark). And, still more confusing, with our IUse
third party's point of view while our support unlocked the
situation and permitted the rough consensus.<br><br>
<br>
1. To clarify the "IUse" term<br><br>
We call "IUser" those who wish to intelligently
"interuse" the Internet. This means that their interest is in
better relating with other parties in the digisphere in every possible
way, including through the Internet. This means that they do not want to
be particularly bound to Internet protocols and practices however they
certainly want that their Internet best practice and clear logic are kept
being use throughout the whole digital ecosystem (WDE). Intelligent use
consists in obtaining more from any technology being used, in a smart
cross technology consistent manner, through an IUI (Intelligent Use
Interface) shaped to better address the specific and generic needs of
categories of users.<br><br>
- Until August 29, this was a concept that was supported but not
clarified by the IETF: RFC 3935 assigns the IETF the goal to make the
Internet work better (but does not explain what working better
means).<br><br>
- Since August 29, the IETF strives to influence an Internet that is to
be acceptable for the global market. This means that IUse (Intelligent
Use) is now a market of people who wish to better use the digisphere
resources, including the Internet, with the assistance of an IUI, at two
sets of layers above the OSI model, providing :<br><br>
(1) extended value services of intellition (filtering the
logical noise and assisting in the enunciation area) and <br>
(2) facilitation semiotic services (filtering the semantic
noise and assisting in the comprehension area). <br><br>
As such we are interested in multilinguistics (the cybernetics of the
linguistic diversity and mecalanguages - the way computers speak and
think, including natural languages - as being the protocols of exchange
within our anthroporobotic world). <br><br>
- IUsers may liaise with the IETF through the iucg@ietf.org mailing list,
and the IUCG (Internet Users Contributing Group -
<a href="http://iucg.org/wiki">http://iucg.org/wiki</a>) the charter of
which is to contribute in reminding IETF participants as to what their
community/market is looking for, trying to help with contributions,
objecting to positions they consider as detrimental for their plans or
reducing the capacity of the core Internet technology to interact
efficiently with its periphery (IUI) to better support us, the users, and
in informing on their own lead users' projects and intents.<br>
<br>
Being a FLOSS initiative, IUsers lack research and notoriety funding. It
happens that there that some concepts, work and people that have gathered
around my positions and initiatives (cf.
<a href="http://iutf.org/wiki/JEDI">http://iutf.org/wiki/JEDI</a>). The
present handling of multilinguistic issues by the IETF is more or less
acceptable to me. This was not obtained easily, as the consensus I wished
for could only be sometimes obtained “against my person”, in a kind of
dissymmetric counterwar of mine to prevent further cultural conflicts. As
a result of my (sometimes clumsy but eventually successful) “mail
combat”, I had been banned several times from this list and I still am
from the general IETF list.<br><br>
<br>
2. The IDNA2008 consensus.<br><br>
This consensus was difficult to reach due to (1) the opposition that Mark
and John have illustrated, and (2) because we (IUsers) actually opposed
both of them, on architectural grounds. Our rationale was that their
opposition is <u>unnecessary</u> and that none of them fully respected
the Internet end to end network model and, therefore, our own fringe to
fringe (cf. RFC 1958) and, above, use to use extended model. There is no
double constraint calling for a compromise. There is architectural design
errors, mostly related to the lack of a presentation layer in the TCP/IP
end to end model. <br><br>
(1) It de facto tied our own open use of our own machines to the
constraints of a non-transparent Internet architecture. Our example was
the lack of support of the French language. We do need to support
majuscules for our delayed experimental ".FRA " project (using
this name space as the open taxonomy of a linguistic ontology).<br><br>
(2) these limitations came from the historic construct of an external
side system (Unicode) and from unnecessarily constraining the way the
Internet architecture permits to support diversity while wanting to
achieve use related issues (like "ss" support) within its
TCP/IP layers set without creating layer violations.<br><br>
(3) for us, their positions were only superficially opposing, as actually
being architecturally orthogonal, as they did not belong to the same
layers once Patrik's inputs and Punycode were accepted. We supported,
however, far more of John and others at the WG because their system was
the Internet internall system. Mark's Unicode system is external. Both
are unfortunately incomplete (no way to directly support basic
orthotypography, no way to oppose phishing). We think we can build
intelligence a top of both, the way they are, to fully address thgeir
concerns, our needs, and more at the IUI, <br><br>
(4) we identified most of the problem as being documented in the first
part of the IAB FC 3869 : this is addressed by our FLOSS approach.
<br><br>
(5) The rest of the problem was to know where we should document and
experiment our solutions.<br><br>
The WG/IDNAbis charter was to support IDNs on an IETF "end to
end" IDNA2008 basis, with a long transition period from IDNA2003 in
order to be less dependent on the Unicode framework and new versions. The
Chair, and most others, made it clear that this was their priority (and
this is what was rightly achieved <u>from a network side</u> point of
view) rather than addressing the actual users’ needs.<br><br>
I had made it clear that once this is achieved, we would pursue the work
and support IDNs <u>from a user side</u> point of view (we called it
ML-DNS), and that at the WG we would oppose what could hamper our future
work. We identified that it meant that users had not to be constrained by
any MUST outside of a committed description of what each entry in the
Internet DNS network service would result into (basically the position of
John, except that he had to kill the upper-case transparency [for
excellent reasons] in his process). <br><br>
<br>
3. RFC 5895<br><br>
Eventually, Paul Hoffman and Pete Resnick came with a conception of the
presentation of our “hidden” common agreement (as being the very nature
of the Internet architecture) that everyone could accept (the text of RFC
5895).<br><br>
This was not done in plainly acknowledging that there are three main
strata involved, but in implying them: <br>
- the Internet internal core (end to end).<br>
- the optional intelligent rings (fringe to fringe specified in RFC 1958
and the use to use of the IUsers) we locate at the IUI and that is
currently in the browser.<br>
- the end-usage.<br><br>
This was documented as being "unusual" for an IETF memo to
document what users should (a SHOULD, not a MUST - this was the key
point) do beyond the ends, i.e. at the fringe to fringe stratum. This
acknowledged the principle of subsidiarity as the way the Internet legacy
architecture actually fully supports diversity, at the very external
roots of diversity <br><br>
- This led to an immediate consensus. <br>
- However, it left us with the basic architectural error of
"IDNinA", the AD started questioning about: <br>
---- the warranty of a unique response to several independent
applications (we see the differences today among browser providers),<br>
---- our protest for the lack of support of French majuscules (therefore,
lack of support of orthotypography, i.e. language cultural typographic
syntax and multiple types of variants),<br>
---- and the discrepancies you note between IDNA2003 and IDNA2008,
<br><br>
<br>
4. The IESG approval of half the solution<br><br>
We pleaded with the IESG for them to accept the IDNA2008 consensus (text
of our Draft:
<a href="http://iucg.org/wiki/Projet.FRA_position_statement_sent_to_the_IESG">
http://iucg.org/wiki/Projet.FRA_position_statement_sent_to_the_IESG</a>).
IESG considered our points and the fact that we eventually reached a
consensus. They quickly approved the proposed RFCs, except initially the
fundamental one - upon our opinion - of Paul Hoffman and Pete Resnick).
So, as announced, I appealed the decision : there also was no
architectural warning about the introduction of the principle of
subsidiarity. This did not brought to the IETF community the fact that
the entire existing architecture could be read as much more powerful than
people thought. No indication was given as to where the remaining issues
on IDNs (pseudo presentation support through "xn--") and the
User side architecture (IUI/browser/applications) had to be discussed.
<br><br>
The response of the IAB and IESG made it clear that this was of interest
to the IETF but that fringe to fringe and user common intelligent
interfacing with multiple technologies did not belong to its charter.
This is why I have engaged in the set-up of the IUTF (Intelligent Use
Technical Forum) and I am preparing the INTF (Intelligent Network
Technical Forum). <br><br>
- At this stage, we have completed a pre-documentation of the Intelligent
Use Interface architectural framework
(<a href="http://tools.ietf.org/html/draft-iucg-internet-plus-10">
http://tools.ietf.org/html/draft-iucg-internet-plus-10</a>) - which is to
be quite enhanced - and are engaging into a prototype development towards
tests next years.<br><br>
- this effort conforms to the 2008 announced charter to support a
multilinguistic (i.e. every language being treated equal) and multi-layer
(different technologies, services, etc.) DNS on top of IDNA2008.
<br><br>
- However, we are no longer only considering an extension of the DNS use,
but an optional intelligent architectural encapsulation of the end to
end/fringe to fringe/use to use digisphere. I.E. to use the Internet core
architecture services as a value added bandwidth for Internet+ extended
services and Intersem (semiotic internet) smart use services.<br><br>
<br>
5. The impact on the browser's model<br><br>
In this approach we divide and augment the Browser's tasks in three
domains: <br>
- the screen/peripheral support<br>
- the local display (presentation) processing<br>
- the DNS resolution.<br><br>
1. the screen/peripheral support should be enlarged to the entire
UI functions. <br><br>
2. Our interest is in a generalization of what has been proven
with the datagram and RESTful concepts. We call them "monagram"
and "referential communications" (metarelations).<br><br>
The role of a monagram is to document all the referential datagrams that
could be useful in considering a particular input. Referential
communications implies to communicate in strategically shopping for these
datagrams in terms of trusted or favorite functions and inputs. For every
"use to use" applications. The collected referents acting as
OPES on the data flows. <br><br>
3. This is why we do not locate IDNA support in each applications
but we rather consider an IDNApplication performing the “IUser's DNS
service” and distribute it across the whole user's "cybship"
(the user's set of networked digital resources).<br><br>
4. This is why we need to be able to disconnect the browser's DNS
oriented services and protections. The job will be carried by a smart DNS
front-end service at the IUI (whatever the IUI type of architecture may
be). <br><br>
This means that the user may enter URL variants in any format (from
applications or through the browser) : they will be transformed in
U-labels at the “ML-DNS” front-end, and then in A-labels in using
IDNA2008+ (i.e. with additions only supported in an ML-DNS environment -
and rejected as errors otherwise - to support orthotypography).
Prior to propose about these escape solutions we want to experiment
(hence, first explore, document and develop) and get defined an universal
digital naming syntax.<br><br>
Best<br>
jfc<br><br>
<br><br>
</body>
</html>