Annex 8. Mail exchange with Patrik Falström
From IUCG - Internet Users Contributing Group
The AD had asked questions. Patrik Falstrom addressed them as a new thread (as PF1). I myself (JFC) asked questions to Patrik Falström's whose responses (as PF2) are listed in a first part. Not to break the rythm of his valuable responses, I mention (as [JFC.X]) my own answers that I list afterward. Patrik Falström did not answered them yet.
On 9 feb 2010, at 16.06, jean-michel bernier de portzamparc wrote:
As requested by Patrik Fälström, I copy these questions to the WG list.
Patrik Falström responded (PF2):
It was requested by JFC, as I did not want to respond to this private mail in private, and he can not post to this list. So he requested you to forward this to the list.
At 23:15 08/02/2010, Patrik Fältström wrote (PF1):
Part from standing behind what Vint wrote in his response, let me answer more directly the questions from Lisa.[The Applications AD]
I am a developer/designer of mostly web based software for management of domain names, web sites, email services and what not. I will (and want to be able to) in my interfaces first of all be pretty sure over what data comes to me as a "server". I.e. I want to know what the end user really wanted to give me (I did explicitly not say "typed" here for reasons I hope people understand).
JFC: I understand that you are on the server end. You are related to a user and you do not know if this is a direct relation, or it goes through a bowser, an iPhone, a Client, a User Agent. Correct? Yet, you also consider the case where you may have to develop the User Client/Agent and you control things down to the user's fingers?
PF2: My point is that what people historically believe is "the user interface" sometimes is a split relationship between what today is a client and a server, where the human have access to the client, and the access to the server is from the client via some protocol like HTTP.
I.e. we have often said that potential mappings should be done in the user interface, and I agree with this, but I wanted to give one example where it technically is very hard to do what is the user interface. IF there is a mandate on some mapping, what software should do it? What software will be compliant, and what software will not be compliant?
It is not as easy to answer those questions as some people might think.
[JFC.1]
PF1: Now, if the web browser (if the web browser was used) did some trick and converted some characters, then I do not get the characters the end user typed (for example), but regardless of this, I will do whatever I want to do to make the end user happy. Exactly what that implies will differ depending on context. Is this domain name management or management of a web site, or the management of email addresses or sites?
JFC: So you mean that the reference is what the user wants to achieve?
PF2: To some degree, yes.
A user should not be surprised. But then what is surprised?
[JFC.2]
JFC: And your understanding of what he wants to achieve will depend on different context inputs, and obviously of the protocol being used and the task to be performed?
PF2: Potentially, yes.
[JFC.3]
JFC: Also from the zone?
PF2: No. And the reason is because of the following:
To be able to give context dependent responses (such as language, username or whatever), the selection mechanism must get information about the context.
And that is not possible to do in the DNS protocol.
[JFC.4]
So some layers in the architecture must be exactly the same, all over the world, for all users, or else it will be impossible to get the base interoperability that is needed to build the systems people wants.
[JFC.5]
Another example, the HTTP and HTML protocols are the same all over the place, but HTTP include a negotiation phase regarding screen size, type of browser etc that makes it possible for an HTTP server to give back different data depending on such information.
HTTP is not different. HTML is not different.
[JFC.6]
PF1: Is this mapping, if applied, to be implemented in the browser or in the web server? I would like to get as raw data as possible, without having the browser doing anything, so that I know as much as possible on the server side. So I can "help" users the same way browsers today "help" users by adding ".COM" TLD if that is not added. "guessing" I think it can be called.
JFC: I understand this is in the case where you have to develop the user client interface?
PF2: Sometimes yes, sometimes no. If you for example on a web server use Wordpress software, you as a user of the site do not develop the software. Are you developing the user client interface? I do not know. I would claim I am not doing that. Do the one creating the wordpress theme do that? I do not know.
It is blurry.
But I want to trust all of those developers "to do the right thing".
[JFC.7]
PF1: And if HTTP/Web browser is not in use, but instead for example an iPhone application that then interact over JSON/Netstring/TCP with some server API, then I can in a more direct way control what is sent to the server (if I also write the client). I will only be confused (possibly) over the mapping that is in the operating system / user interface libraries.
JFC: OK. Did you think of a method for you to clarify that possible confusion?
PF2: Only by giving me the ability to implement mapping or not depending on what "makes sense" for me, and my application.
[JFC.8]
I am VERY nervous over having any kind of mandatory mappings. Mandatory for whom? Who must implement it?
[JFC.9]
---
PF1: All of this might sounds like if it will make things messier for the user, but in reality I do not think so. *NO* developer have the interest in making this messier for the user. And exactly what it means to make it easier for the user depends on context. Very much. Specifically when we have so many protocols and environments and contexts where domain names are in use.
JFC: As I said, I am not that much competent in Web level applications, rather with user level interapplications. Which documentation do you use to identify how you should understand what to do with a given protocol, in a given environment, for a given context?
PF2: I will use whatever I can find. Often I am looking at what is done in local language communities. At the moment IANA Language tables.
[JFC.10]
PF1: Saying just "no mapping at registration time" is not good enough for me. What about if you want to change the holder or adminc or techc of a domain? Should you do mapping then, if the domain name is typed by the user or not? Is a transfer of a domain name "registration time"?
JFC: Good point. What if the Registry sotfware does not consider holder/adminc/techc and uses a different system?
PF2: They all do. They might use different terminology.
[JFC.11]
JFC: What is the Registry only use local script/language interfaces?
Many only support interfaces in local script and local language. I do not see any problem with that.
[JFC.12]
PF1: No, I rather see that I as a developer can do whatever I want to make things easier for the users, and that might include that I try to do some mappings of codepoints that are not PVALID, or complete changes of some things that might be domain names (hard to know sometimes) to something that are domain names (different separators between labels for example).
JFC: and French/Latin language majuscule support?
PF2: I can not be more precise than what I was above.
PF1: So to answer your question Lisa: No, it is not clear what characters are suggested to be mapped, but we do not even know where or who has the responsibility to do the mapping -- if any. In the case of HTTP, is that done in the web browser or on the server side, in the cgi?
JFC: I have some difficulty here: how can an IDN be mapped on the server side? Should it not necessarily be mapped on the user side so it can be properly resolved to that very server?
PF2: "server" as "server side" in HTTP. Not server side as in DNS server.
PF1: For example how do a web browser know whether the ajax / json call is to be "a registration" or not? A situation when mapping should explicitly not occur? It can not, and because of that browsers should not include any mapping at all. Ever.
That is one view, and of course you can find the arguments the other way around as well.
JFC: I agree with your position. Would you know of an online document/discussion on this matter, or a con/pro list?
PF2: I think the IDNA mailing list archive is a good source...
[JFC.13]
PF1: And this is why I think the current mapping document is as good as we can get it -- and why I think (like Pete) TR46 is too strong. Because it is very wrong to explicitly ask for mappings the way it does.
JFC: Do you know if other possibilities have been expressed by W3C, or SDOs?
PF2: TR46 is one of the documents. I know ITU and UNESCO also are doing work, but they have been waiting for the RFCs to be published. ISOC might come out with something. ICANN might write recommendations. Etc.
[JFC.14]
PF1: What *might* be ok and good to do is to say what codepoints can be mapped in various contexts to other characters, but I think for example the definition of bundles in the IANA registries to some degree do that. When not mapping from PVALID to other PVALID of course. So that people know that IF one work in a specific context (certain language for example), THEN it MIGHT be interesting to map from A to B.
JFC: Do you consider the possibility of mapping on a TLD basis?
PF2: No.
I think the user wants mapping based on other criteria.
[JFC.15]
But of course the TLDs already today via the language tables do implement in some cases bundling and various policy based issues.
[JFC..16]
PF1: So I would say the mapping document we have is good.
JFC: How would you qualify it? a reminder, a protection against too stringent or lax behaviours, a guidance, a reference, a open link to further work? Is its informational nature not a problem while it completes a standard track work?
PF2: We do not know yet. Let people try, and we see. Having guidelines is ok, and probably what developers need.
But mandatory rules, nope.
[JFC.17]
Patrik
[JFC.1]
Correct. This is where I identify there are four possible IDNA user localisations:
1. in the user interface to the client 2. in the user client. 3. as a unique IDNApplication that serve the client 4. as a part of an IUI (Internet Use Interface) in between the client and the plug to the network where the server is plugged.
1 & 2 are OK for testing, not for user operations. There are as many experiences and possible different resolutions as there are applications or clients.
3. is more secure, can have a control panel, support local config files. But user applications must know that service application and how to dialog with it.
Only 4 permit localization issues to be locally centraly managed and networkization issues dealt through it with the ISP in order to permit a semantic relation with the server cleared from the context and identical with every existing protocols (the IUI looks to them as a pseudo-network they can ignore). You may have scores of applications using IDN without knowing it if they are UTF transparent.
[JFC.2]
We agree. And this is where I say that the IUI must be intelligent enough to be able to make a difference between localization and personalization issues. Also, it means that there might actually be different Ulevels depending on personal, local, etc. mapping (i.e. for example a simple equivalent to Host.txt being supported)
This is why I refer to a Multi-Layer Domain Name System pile with
- what the user actually types,
- which can be different from what the client will accept
- that can be different from the real Ulevel
- and then the actual Alabel
All of them must strictly polynym (synonym in their context) for the user (this may change from users to users). This can be very common if the resolution may also be made outside of the DNS in other environments also using the IDN (IRI, semantic addressing, etc.) This is why I prefer to refer to IDNs as "Internet Domain Names" with a single simple syntax that covers DN and IntlDNs alike. This permits to consider that IntlDNs only are internet domain name of the "xn" presentation. The IUI having the job of sorting presentations and classes.
Presentations are simply the two letters before double dash (IDNA uses the xn-- "extended names" class). Classes other DNSupported pay loads can be introduced by single letter + --.
1. the Internet presentation layer emerges from this, with years of validation behind by i-DNs and IDNA2003 2. I have a universal syntax available to support presentations and any semantic. To make it universal I consider that Internet Domain Names syntax is alphadigital labels and sub-labels with "." (or something else) as intelabel, and "-" or (something else) as intersublabel. Double dash corresponds to an empty sublabel that separates metadata payload from naming payload.
[JFC.3]
Agree.
[JFC.4]
Yes you can.
I can decide that .fr do not support French majuscules because it never had. And that .fra does, because it is designed to be semanticaly clear.
[JFC.5]
Correct. This is why the architecture needs to be more precise and support the needed flexibility up to the point IDNA2008 defines. This is this way that IDNA2008 defines multiplicity. It is the ultimate required point where architecture must be the same, all over the world, for all users. As such it defines the boarder of the IETF scope. This is why I identify:
- the Internet system, the IETF scope of responsibility : IDNA2008
- the Internet exotem, the user area that wants to use IDNA2008, documenting it is what I call IDNA2010 in order ICANN does not continue to use the word wrongly
- the Internet peritem, the fringe between the Internet system and the user's Internet exotem. Documenting the way this peritem information must be presented is what I call IDNA2012.
As Project.FRA I have a need. I know that to solve it I need to get my users to treat .fra differently from .fr.
How can I do that?
Very simply: in having my users using "punyplus" as an algorithm rather than "punycode". When they find a TLD or an upper level domain (can be several level) ("ULD", also a "User Level Domain") listed in their "netlocale" their IUI is going to localize it as indicated in the netlocale file.
The same, if they need something special (for example kidprotection filtering) the punyplus algorithm can be used to filter as documented in a "personale" file. Punyplus and the netlocale file formats and possible management system need to be documented.
My suggestion is that IETF can use:
- MUSTs for its system
- SHOULDs for the peritem fringe
- MAY for the user exotem, like Mapping does.
[JFC.6]
Absolutely. This kind of functions (server front end and IUI can be performed by OPES - the HTTP OPES has been specified).
Now, the problem you raise that it is not possible to do it through the DNS protocol is more a question of capacity if there are millions of TLDs to filter, update, etc. This is true on the Internet network side. This is not on a user side.
If instead of a unique unique root file, you consider a unique virtual root file that people can partly implement through their "personale" file. They just maintain the TLDs they are interested in. There are 25.000 sociolinguistic entities: I am able to read or grasp just a tiny few. I wish to filter out what I do not want (and not what Unicode wants, hence the dispute about RFC 4646).
[JFC.7 ]
You cannot. First a whole because some are breakers, phishers, pirates, etc.
This is why I tend to say, what the user feel as the "network" MUST be what his machine perceives as the network (this can include non-Internet networks). In order to achieve this, I consider that "user side network applications" must be considered as forming a dedicated network layer, where they appear as "smart local operating tasks" (slots) to clearly identfy the from their brother at networking the Internet network applications (Mail, DNS, etc.).
They locally operate tasks the user consider as parts of his "smart Internet system", whatever it may really be. The user will access them through the browser or some dedicated local interface. Hence I call the slot layer "pseudo-network" as it is seen by the user as an intelligent network shell.
Now, I put that slot layer in the IUI, so there is a clean overlay :
- through the IUI the network expand on the User side.
- through the IUI the user controls the fringe of the network. This permits to differentiate :
- dump traffic (passive content) from end to end
- smart traffic (ambient and active content) from IUI to IUI
Then I observe such slots have much in common and that it could be nice for them to interoperate with other local slot servicing them, or with remote fellow slots to support metatraffic. This is why I add interapplication layer - between the Internet network application layer and the IUI network application layer.
Then I obseve that there can be advantages in locating network applications in the Internet (global range network applications) and in the IUI (local range network applications).
Let take the example of the DNS. If I put the DNS in the IUI it is both part of the Internet DNS and dedicated to my machine/small-home-network (SnHn) or duplicated within my own Internet context (cybship: all the digital resources I control). To be sure there is no pollution I turn recursion down, making it secure.This means that now I can use my own local root, with just the TLD/ULDs I am interested in from the unique virtual root classes (I can add my own ULDs as China does with its own IDNgTLDs).
[JFC.8]
OK. This is where I say there is an urgent need for Internet Adminance (i.e. technically managing the internet in cooperation, so all this can be documented by who is actually responsible). But this calls for flexibility, simple and robust rules, etc. This is why I say the IUI needs an interapplication system that permits network applications. Naturally called it "Netix". And I can easily support it in using the ML-DNS syntax.
This way Netix in the IUI makes a complete interoperable addition to the Internet basis able to match the user's expectation for an intelligent open network of his own understanding, using its own classes and presentations, ML-DNS pile, interslot authentication
[JFC.9]
Sure !!! But having a mandatory syntax to express a free mapping semantic may help. Moreover it can be multilingual and users can enter parameters or use scripts.
[JFC.10]
Correct.
This is why I need all this and much more to be federated in a structed open repository that applications can directly access. A local customized IANA.
I call it the Multilingual Distributed Referential System (MDRS). It should be ISO 11179 compatible to interoperate with many other registries.
As you say, most is documented on a local language community basis. This is why I documented the ccTAG concept with people from ISO, MAAYA, Linguasphere, etc. They are just a reference grid, a continuation of ISO 3166 (we use to call ISO 3166-4). ISO 3166 includes for each country the administrative (i.e. normative) languages and scripts using ISO 639 and 15924 codes. So ccTAGs proceed in the logical categorization order: country, script, language, region - supported by the core document of international consistencuy, including Internet and ccTLDs.
The technical interest is that being polylingual (French/English) and listing the Govs, i.e. the standardization authorities, it can be understood as the French and English instantiations of a single multilingual standard with equal validity in every normative language (what we call "polynym", synonym in different context).
Due to the universal acceptance of ISO 3166 it continues the Internet intrastructure as it is since 1978. Very stable, accepted, intuitive. This means that I can tag every application linguistic instantiation in a congruent manner with its administrative forms, sales contracts, vendor rates and support, local regulations, etc.
Also, that through ISO 11179 compatibility the MDRS can be indefinitly expanded as a metastructure, ready to support the Intersem (semiotic/semantic internet) needs.
[JFC.11]
All ccTLDs do not adhere to the ICANN WHOIS concept which actually is illegal but tollerated in most of the countries (violation with local privacy laws). Zone Managers can be at any level and be sure that many ULD managers will not even know that ICANN exists or what it could have to do with their Private Class TLD. ICANN is only for class IN.
[JFC.12]
Sorry, I meant at application layer, not at user layer.
Internationalization means that local language is embedded in English. Multilingualization means that local language replaces English.
This is the conflict I had with Unicode because their Globalization is internationalization+localization+flangtag-filtering. In the fussy process we identified the existence of multilinguistics as the discipline of the cyberntics of the linguistic diversity. How languages interelates among other languages and/or cultural entitities.
[JFC.13]
OK
But I thought about something more formal and organised.
I compiled all the WG/LC remarks in a Draft. Indicating which had been answered. I lost the count of the non-answered ones.
http://www.ietf.org/id/draft-iucg-wgidnabislc-01.txt (or better reading: http://wikidna.org/index.php?title=WG-IDNA_LC)
[JFC.14]
Dont you think a common work could be usefull ? Users are not interested in consensus, but in multiconsensus, i.e. a consensus in each of the position groups, and a general consensus on how each position bridges with the others. Beging in using a single terminology and possible comparison tables.
[JFC.15]
For example Project.FRA wants majuscule support based on .fra while .fr may npt mind or address the need differently.
[JFC.16]
I am interested in what I call mecalanguages. i.e. natural languages as to be spoken by machines. The risk is that they become the referents and that languages rigidifies or split (machine/human). But the risk is, now on an interactive basis, equivalent to dictionnaries and grammars. The mecalanguages must be able to adapt and support dolwn to avalects (languages of each individual avatar's styles) (hundreds of billions). The only serious non-physical personal authentication is based on avalects as it betrays the cerebral status.
Now, the challenge is to work on the invarients, i.e. the semantic traits or atoms, that can then be passed as metadata (as one passes Alabels) and restored through different mecalanguages. This gives the idea of Ulabels that could display differently depending on the context.
This is certainly possible as part of the ML-DNS (multilayer domain names pile system - the minimum of it being the Alabel/Ulabel pile. Domain Names cannot refer to invariant, but semantic addressing can do it while using the DNS as a support. This is one of the targets of the Project.FRA in using its namespace as a taxonomy for an open ontology.
[JFC.17]
Who in your opinion should work these guidleines after the experience of this WG, i.e. working relations with Unicode, IUCG, i-DNs, ICANN, ITU, etc. ?
We have a MAAYA Unesco meeting on 23/24 to prepare a book on multilingualism in cyberspace. I think we should start with some kind of ontology of multinguinstics and cyberlinguism, i.e. the way languages behaves together and the way cyberspace affects languages. But we will know better when we know what others may mean when we use the same words as us.
This is why I say that now we have built the Internet side IDNA, one has to consider the User side and the intrastructural side (guidelines, tables, information, registries, etc. ): where and how the developper information should be stored and found.
