Re: Updating RFC 5890-5893 (IDNA 2008) to Full Standard

[JFC Morfin <[e-mail]>]

At 00:15 17/11/2012, Vint Cerf wrote:

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

Anne,

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.


1. To clarify the "IUse" term

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.

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

- 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 :

   (1) extended value services of intellition (filtering the logical noise and assisting in the enunciation area) and
   (2) facilitation semiotic services (filtering the semantic noise and assisting in the comprehension area).

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

- IUsers may liaise with the IETF through the [e-mail] mailing list, and the IUCG (Internet Users Contributing Group - http://iucg.org/wiki" rel="nofollow">http://iucg.org/wiki) 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.
 
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. http://iutf.org/wiki/JEDI" rel="nofollow">http://iutf.org/wiki/JEDI). 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.


2. The IDNA2008 consensus.

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

(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).

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

(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,

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

(5) The rest of the problem was to know where we should document and experiment our solutions.

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 from a network side point of view) rather than addressing the actual users’ needs.

I had made it clear that once this is achieved, we would pursue the work and support IDNs from a user side 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).


3. RFC 5895

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

This was not done in plainly acknowledging that there are three main strata involved, but in implying them:
- the Internet internal core (end to end).
- 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.
- the end-usage.

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

- This led to an immediate consensus.
- However, it left us with the basic architectural error of "IDNinA", the AD started questioning about:
---- the warranty of a unique response to several independent applications (we see the differences today among browser providers),
---- 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),
---- and the discrepancies you note between IDNA2003 and IDNA2008,


4. The IESG approval of half the solution

We pleaded with the IESG for them to accept the IDNA2008 consensus (text of our Draft: http://iucg.org/wiki/Projet.FRA_position_statement_sent_to_the_IESG" rel="nofollow"> http://iucg.org/wiki/Projet.FRA_position_statement_sent_to_the_IESG). 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.

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

- At this stage, we have completed a pre-documentation of the Intelligent Use Interface architectural framework (http://tools.ietf.org/html/draft-iucg-internet-plus-10" rel="nofollow"> http://tools.ietf.org/html/draft-iucg-internet-plus-10) - which is to be quite enhanced - and are engaging into a prototype development towards tests next years.

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

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


5. The impact on the browser's model

In this approach we divide and augment the Browser's tasks in three domains:
- the screen/peripheral support
- the local display (presentation) processing
- the DNS resolution.

  1. the screen/peripheral support should be enlarged to the entire UI functions.

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

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.

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

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

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.

Best
jfc