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