support of metadata

jean-michel bernier de portzamparc jmabdp at
Fri Sep 18 11:17:11 CEST 2009

Dear Nicolas,
thank you for the tip. I actually considered that hypothesis to make sure
that Harald and I understood well each other. We actually have started
working on a text that begins where IDNA ends (

FYI we are not interested in accents, since IDNA supports them well. We are
interested in the metadata that a character is (1) an upper-case (2) a
majuscule, i.e. an information that one usually buries in the upper-case
information. So far, in IDN the upper-case information is enough. But it
would be better that the IDN practice be the same as a general practice. A
general practice means that Unicode should support codepoints for these two
metadata. The hack I proposed is not to patch IDNA but Unicode in the way
IDNA uses it.

Unicode used to support language tags. They seem now to prefer the RFC 4646
environment to transfer that information. This has the advantage of
permitting a network consistent environment, but does not help the network
behaviour itself when the granularity is smaller than a datagram, like in
the IDN case.

We could use this very mechanism that is now obsolete. Or create a new one,
but the Unicode consortium could easily confuse it if they disagree with our
user' approach. Anyway we need a leaner mechanism that is also well
supported by punycode. The easiest is an upper-case prefix (UMI, uppercase
metadata indicator); but we have to chose it well, until it is standardized
in ISO 10646.


2009/9/18 Nicolas Krebs <nicolas1.krebs3 at>

> jean-michel bernier de portzamparc wote
> >If I take the
> >protocol and table document and just change these two points and call it
> >IDNAPLUS, explaining how these two points can be blocked in order to only
> be
> >IDNA conformant, I can publish them as IDNAPLUS RFC?
> Except copyright, trademark, patent issues, you can publish anything you
> want.
> For copyright issues, if you "just change [...] two points", the easiest
> way is to
> wrote that your specification do not differ from IETF RFC XXXX except for
> the
> sentence xxxxxxxxxxxxxxxx replaced by yyyyyyyyyyyyy.
> For trademark issues, see relevant RFC (I guess you should not use "IETF"
> or
> "RFC" in your specification's title)
> For patent issues, see relevant RFC.
> _______________________________________________
> Idna-update mailing list
> Idna-update at
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Idna-update mailing list