[vip] oups!

[JFC Morfin]

Please read:

In French:
Etat = Government
état  = status

Upper-cases can or not wear an accent. There is no difference. In 
ASCII "etat" is supposed to mean both. This kind of confusion cannot 
be accepted due to its semantic impact.

Also, please remember that in this case "E" is just a way to express 
(in using an upper-case) that E is a majuscule. Unicode has no other 
way to support the "majuscule metadata" that upper-cases: this is why 
I said that the lack of upper-case support by IDNA2008 (to the 
contrary to IDNA2003, which did not affect upper-case entries from 
end to end, as the DNS does not either) was not bad. It implies the 
mandatory use of an added middle-netware (I call the IUI and which 
will offer intelligence on a fringe to fringe basis, between the 
user's computer plug and its unchanged OS socket. cf. IAB RFC 3238 on OPES).

As in some other scripts, the important thing is not to transport the 
same typography on an end to end basis, but to carry the same 
message, i.e. data + metadata, on a fringe to fringe basis.

Architecturally this important because it affects the kind of 
technical communication stratum we consider.
-  In value-added datacommunication (OSI, TCP/IP) the model includes 
communications oriented metadata in the envelope (along the layers of 
that model). If there may be a need for the content to be accompanied 
by metadata : these metadata are conveyed by the "presentation" 
layer. IDNA2008 institutes the missing TCP/IP presentation layer 
through the rudimentary "xn--" prefix. This is rudimentary because 
the metadata is correctly in the header, but not directly accessible 
(not at a structural address).
- the stratum above telecommunication (no metadata) and 
datacommunications (metadata in the header) is the metacommunications 
where metadata are sent/obtained by their own.

There are therefore two ways to deliver the othotypographic 
"majuscule" pay-load:
- either in using the domain name. We still are in the rudimentary 
solution, but we can improve it if this becomes a stable extended way 
to proceed.
- or in paralleling the data delivery with a metadata delivery ("the 
first character of the related domain name is a majuscule"). In this 
case we are outside of the standard telecommunications 
and  value-added and extended datacommunications: we have entered 
metacommunications. To date the Internet is not a metacommunications 
technology.

The possible improvement to support metadata, hence to support 
variants, can be:

- to use another presentation, in changing or extending the "xn--" header.
   - xm-- means that the first letter is a majuscule:
   - "xn--5-- means that the fifth character is a majuscule or is a 
figure to take into a local list of numbers
   - etc.
- in extending the punycode syntax and introducing an escape signal. 
for example "état"="status" and "^état"="Etat".
- in acknowledging that this leads to a change of the nature of the 
domain name field in the TCP/IP packet. It becomes the presentation 
layer support. This calls for a presentation protocol defaulting to a 
regular ASCII FQDN.

However, this definitely belongs either to the UI in the current IDNA 
IAB architecture,  or to the IUI in the traditional Internet 
architecture as IDNA2008 read it and in the multitechnology digital ecosystem.

This leads to the questions:

1) how does this WG/VIP intend to see its conclusion technically supported?
2) Will ICANN publish an IDNA/ICANN stringprep/stringextract function?
3) Will it develop or specify an IUI?
4) or will it publish its findings as a multilinguistics contribution.

jfc