Subject: [precis] the Exceptions category

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 07 May 2012 20:50:56 -0600

RFC 5892 defines a category called Exceptions, which lists codepoints
whose assignment differs from what the assignment would have been based
solely on the core property value. For example, while working on the
PRECIS codepoint table I just found U+0F0B (TIBETAN MARK INTERSYLLABIC
TSHEG), which has a core property value of Po ("Punctuation, other") and
which thus would have been DISALLOWED in IDNA2008 if it had not been
explicitly placed in the Exceptions category.

Unfortunately, the decisions of the IDNA2008 team with regard to these
exceptions are not documented in RFC 5892 or elsewhere (AFAIK), so it's
not easy to understand whether it would be best for PRECIS to follow
IDNA2008 here or instead to base our assignments on the core property
values for some or all of the codepoints in the Exceptions category.
(Using the same example, if we follow IDNA2008 then U+0F0B would be
PVALID, whereas if we base assignment on the core property value then
this codepoint would be FREE_PVAL and NAME_DIS.)

I understand the reasoning behind codepoints like sharp S and Greek
final sigma because they were extensively discussed on the IDNA list,
but other codepoints were not as controversial.

I suppose the safest course would be to follow IDNA2008 here. The
second-safest course would be to base all assignments on the core
property value. The least safe course would be revisiting each codepoint
individually and thus defining a PrecisExceptions table that differs in
subtle ways from the IDNA2008 Exceptions table.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: JFC Morfin <[email-masked]>
Date: Tue, 8 May 2012 18:34:31 +0200

> subtle ways from the IDNA2008 Exceptions table.

Peter,

IDNA is actually two things.

1. the way the Internet technology addresses the linguistic diversity
in using ASCII in the DNS.

2. as a result, how the external world, is to assume the Internet
technology interfaces the linguistic diversity.

Hence,

1. non-Internet technology applications of any nature will take
IDNA2008 as the implied multilinguistic model.

2. non-DNS internet protocols should consider that external protocols
and applications will expect they comply with IDNA2008.

3. non-DNS internet protocols will expect that DNS and other non-DNS
protocols will comply with IDNA2008.

Now,

1. it seems advisable to follow IDNA2008 as a default.

2. if there are cases where it looks advisable not to follow IDNA2008
internally

2.1. either protocol external I/O should comply with IDNA2008
2.2. or protocol special I/O with an other protocols could be devised,
provided the group of the two (or possibly more) protocols externally
comply with IDNA2008.

This last point is noteworthy. In the case of my Internet+ Draft,
there will be IDNA2008 extensions (IDNA2008+) to support
orthotypography and variants. However, the Internet and the Internet+
are different strata (goup of layers) with my documented IUI
(intelligent use interface) in between. The IUI will take care of the
interface between the Internet IDNA2008 and the Internet+ IDNA2008+.

As an exemple: let suppose that upper cases are supported by the
ML-DNS (multilayer DNS) as the format "A" > "^a" (^ being a code point
to determine), the resulting name will be a punycoded ASCII
transparent to the Internet internal protocols.

As a reminder, Internet+ stands for Internet PLUS (plugged layers on
the user side), i.e. added intellingent network layers extending the
OSI model as documented by RFC 1958 which stipulates that everything
which is not end to end dump protocols is to be addressed at the
fringe. The internet+ is fringe to fringe and results from the RFC
5895 consensus which permitted the IDNA2008 consensus, introducing
subsidiarity by the users over a stable sustainable internal Internet
technology as a response to the distributed diversity of the Internet
external world. A current operational first Internet+ experimentation
is Google+.

Best
jfc