Re: [newprep] WG Review: Stringprep after IDNA2008 WG (newprep)

[JFC Morfin <[e-mail]>]

At 19:30 11/05/2010, IESG Secretary wrote:
>A new IETF working group has been proposed in the Applications Area.  The
>IESG has not made any determination as yet. The following draft charter
>was submitted, and is provided for informational purposes only. Please
>send your comments to the IESG mailing list ([e-mail])
>by Tuesday, May 18, 2010.


As I have explained, and been opposed for that, many times, it was 
necessary for IDNA that an independent domain name character set 
(DNCS)  eventually be worked out. It was to be adequately formed in 
using ISO 10646 code points, to permit easy interoperability. The 
process used to prepare a UCS string into a DNCS string, could be 
named a "domainization".

My reading of the concerned parts of IDNA2008 is that it has achieved 
a first big step towards that end, what permitted my consensual 
support. IDNA2008 is related but independent from Unicode. A 
difficulty remains however: the support of Latin language majuscules 
and other orthotypographical issues (i.e. not the way machines but 
people's languages use characters)  because the Unicode format does 
not support metadata.

Yet, I only consider such a DNCS in-parts as a super-set of a 
"multilingual registry regular character set" ("regcode") prepared in 
the same manner, but also with anti-phishing considerations, so that 
the resulting charset can serve as a secure man/machine 
multiorthotypographic universal charset (passports, security cards, 
operating system commands, databases, ISO 11179 registries, etc. and 
metadata). So, this regcode can be the Internet presentation layer 
character set.

This is why a secure "regcode" encoding table should eventually be 
produced that could be based upon Unicode + lingual context, and be 
attached to ISO 3166, in using my ccTAGs 
(http://tools.ietf.org/id/draft-mltf-jfcm-cctags-01.txt) for a unique 
secure international sorting and indexing order that could be used in 
"internatioperable" applications. (ccTAGs are my proposition of a 
stable, standard rooted, of tagging legal orthotypographies that can 
be used by networked machines, when langtags correspond to subjective 
linguist classification).

Such a regcode will permit to address the international and Internet 
protocols' needs through a standard "regularization" process, and to 
free Unicode from every network operations constraints.

This issue is going to be a part of my IAB level appeal, because 
IDNA2008 is (per its charter and by its results) a severance of the 
Internet from Unicode. The responses to the questions legitimately 
raised by the proposed charter do in fact belong to the IAB guidance 
that I claim IESG should have requested before approving IDNA2008 - 
or quoted in a disclaimer indicating that IDNA2008 is the network 
side of multilingualization, not the whole of it.

As you know, some consider that the other part belongs to the UI 
(User Interface, cf. "resman" draft 
<http://www.ietf.org/internet-drafts/draft-resman-idna2008-mappings-01.txt>http://www.ietf.org/internet-drafts/draft-resman-idna2008-mappings-01.txt). 
I personally think that it also belongs to the architectural IUI 
(Internet Usage Interface) introduced by IDNA2008 if one are also to 
respect the constraints investigated by the IAB in its Domain 
Internationalization draft 
<http://tools.ietf.org/html/draft-iab-idn-encoding-01>http://tools.ietf.org/html/draft-iab-idn-encoding-01 
(i.e. the question raised by the AD at the end of the IETF/LC and 
left open by the "Mapping" Document). This is why these two document 
are important. As important as tedious but comprehensive enough 
(<http://www.ietf.org/iesg/appeal/morfin-2010-03-10.pdf>http://www.ietf.org/iesg/appeal/morfin-2010-03-10.pdf) 
compilation of my IESG level appeal for those wanting to get the 
details and grasp the context of the problem at sole IDN level.

This is why, through UI or IUI, the work this Charter considers is 
necessary to complete a more comprehensive review. This can only help 
the [e-mail] work on the IDNA2008 user side, and the 
IDNA2012 work on their common adminance [technological 
administration, maintenance, planning].

However, I would suggest not engaging in it, before the IAB has 
published its position on the matter in response to my appeal (family 
obligations as you delay me quite a lot).

Your response to my appeal shows that you accept that the issues I 
raise are worth an I_D and a BoF (or several ones since there are 
several major (IMHO) concerns which should be consistently investigated).

However, until IAB has commented your answer, I do not really know in 
which area (if any) such IUI related issues (including the issues 
concerned by this charter) should be discussed.

Please remember that IAB has initiated a Draft on IDNs that, at least 
for the time being, seems to contradict the very IDNA2003 
architectural principle of IDN in Applications and lead to consider 
an "IDNApplication" that would certainly impact your evaluation 
process because it would permit more flexibility on the user side. 
Actually, my own ML-DNS proposition would be much more flexible but 
at the same time much more defined in terms of "stringprep" equivalent.

Basically, one cannot have _several_ software modules in different 
convergent computer technologies that may convert and resolve 
strings, semantic addresses, domain names differently.

So, I fully support the beginning of the Charter: to evaluate the 
need. However, I do not think the need is "applications" - but use 
and users oriented, so the charter should be very open (like a 
rechartering once the evaluation is completed?) to best locate and 
charter the next step.

I was opposed by Yao Jiankang that "NewPrep" does not want to focus 
on IDN, but internationalized string, there is a difference.

I think I explained that I am not interested in domain names per se, 
but in coherence in the way international strings are handled.

More importantly, I feel that the first thing to be done is to 
consider if the intended works is to be a set of Charset patches, or 
to fit in the Internet architecture which is now based upon RFC 1958, 
RFC 3439 and IDNA2008.

I am only interested in the later. This is why I disagree with the 
ambiguous "internationalized string" wording. Because we should not 
necessarily replicate alternative solutions (RFC 1958) and because we 
also should strive for the simplest one (RFC 3439). If we want this 
work to be of use, we need to discuss universal services character sets.

The target is to support a multilingual universal networked system, 
where IETF so far has tried to diversely internationalize functions 
of an ASCII network system. Today, based upon experience we reached 
the point where the IDNA2008 character set seems a good enough 
working basis for such a multilingual universal network system 
character set. This is why for clarity sake I call it "regcode" 
(regular code) and its use in replacement of another system (i.e. a 
general StringPrep function) "regularization".

I can already list as constraints:

-          "user readyness",
-           interoperability with ASCII and ISO 10646 code points,
-          usability by IDNApplications (users side) and IDNA (network side),
-          as being much phishing proof as possible,
-          orthotypographically acceptable (no semantic value having 
to be bent/lost due to regcode constraints)
-          to be unambiguously multilingually/scripturally sortable 
throughout all the world digital ecosystem (for example in being able 
to be used with my ccTAG proposition).
-          I also add as a major constraint: its universal usability 
by IUI slots, what implies a common adminance of this regcode.

In a nutshell we need a world digital ecosystem equivalent to ASCII 
(when UCS is a complete CS for typographers).

As I explained, at this stage I am questioning the IETF through a 
possible three steps process (appeal to IESG and IAB, possibly ISOC 
further to experimental operations) in order to know

-  (1) in which kind of Internet architectural understanding should 
we now operate
-  (2) who should lead its adminance [technological administration, 
maintenance, planning] (because precisely we do not focus on IDN, and 
even not on network issues) and on which grounds.

This leads to a very simple question here:

-          should we adapt a code to existing functions,
-          or adapt protocols and functions to a code - and then which code?

As far as I am concerned I know we need an IUI system wide character 
set encoding, and I need all the listed functions to be 
interoperational through the IUI (i.e. on the Internet side and the 
convergence with other technologies, standards, and users sides).

jfc