Subject: [precis] draft slides for precis-framework

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Jul 2011 19:24:58 -0600

I've created somes slides about draft-blanchet-precis-framework for our 
discussions next week:

http://www.saint-andre.com/ietf/ietf81-precis-framework.pdf

Feedback is welcome. I'll provide a final version to the chairs before 
our session on Thursday.

Peter

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

---

From: Florian Zeitz <[email-masked]>
Date: Wed, 20 Jul 2011 14:18:16 +0200

> Feedback is welcome. I'll provide a final version to the chairs before
Feedback:
Maybe I'm misguided, but I disagree with the "No more big tables"
statement. You either need at least a code point to General_Category
mapping and a way to tell whether a character is compatibility
decomposable as input for the algorithmic classification, or a table
containing the result of of the classification. Both seem relatively
large to me.

Also (and I'm going to repeat it until someone tells me why I'm wrong or
acknowledges it), "Any character with a compatibility equivalent" is not
what you mean, neither on the slides nor in the draft.
It should be "Any compatibility decomposable character".

--
Florian Zeitz

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 20 Jul 2011 09:16:36 -0600

> containing the result of of the classification. Both seem relatively

Perhaps "no more big tables maintained by the IETF" would resonate better?

-- 
Joe Hildebrand

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 20 Jul 2011 09:30:14 -0600

On 7/20/11 9:16 AM, Joe Hildebrand wrote:
> On 7/20/11 6:18 AM, "Florian Zeitz"<[email-masked]>  wrote:
>

Yes, that's more accurate.

/psa

---

From: Florian Zeitz <[email-masked]>
Date: Wed, 20 Jul 2011 17:31:37 +0200

> Perhaps "no more big tables maintained by the IETF" would resonate better?
Did the IETF itself ever maintain one?
There is still the "PRECIS Derived Property Value Registry" mandated by
section 9.1 to be maintained by the IANA, which (as I understand it) is
basicaly the "table containing the result of the classification" that I
mentioned.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 20 Jul 2011 10:27:01 -0600

> basicaly the "table containing the result of the classification" that I

All stringprep processing was based on a lookup table. In theory, IDNA2008 and PRECIS are based on an algorithm. Yes, there are tables at iana.org, but those are not supposed to be normative. Granted, you still have big tables in Unicode, but not separate tables at iana.org in addition to the base tables of Unicode properties.

/psa

---

From: Florian Zeitz <[email-masked]>
Date: Wed, 20 Jul 2011 23:19:19 +0200

> All stringprep processing was based on a lookup table. In theory, IDNA2008 and PRECIS are based on an algorithm. Yes, there are tables at iana.org, but those are not supposed to be normative. Grant…
So, algorith-wise we're switching from a bunch of big custom tables to a
huge table maintained by someone else.
For implementers caring about code/executable size that's probably about
the same.
>From a specification/standards point of view I see the merit/your point.

BTW what the word for how when you mentioning two things focus always
goes to the one you cared less about? ;)

---

From: JFC Morfin <[email-masked]>
Date: Fri, 22 Jul 2011 03:14:01 +0200

Apps-discuss teach internationalization needs to their members.
http://www.saint-andre.com/ietf/i18n-intro.pdf

Then PRECIS (stringprep) has also its set of slides: 
http://www.saint-andre.com/ietf/ietf81-precis-framework.pdf

These two problems are intricated because they share the same 
problem: the sustainable use of Unicode.

At 23:19 20/07/2011, Florian Zeitz wrote:
>For implementers caring about code/executable size that's probably 
>about the same.

The problem is that Unicode is still an inadequate asolution to 
support computer network use by real people. And that majuscules are 
still not supported what makes the whole considered things 
"senseless" (I mean semantically lame) for Latin languages, in 
particular French. I did not see the main point quoted in these 
slides, which is orthotypography.

As long as one considers that the Internet is 7 bits ASCII I am 
afraid we also do not perceive the problem correctly, what means that 
we will most probably be unable to explore the right solution, 
whatever it may be. I know getting rid in part of Unicode and 
changing our reading of the Internet technology is something hardly 
conceivable, hence inacceptable. However, this is what we just did 
with IDNA2008.

Because everyone wanted to be free from Unicode versioning and users 
could not accept Internet internal mapping. We now need 
multilinguisation, i.e. the coexistence of every language on an equal 
footing and a physhing-proof universal character system. The best 
stringprep solution is no stringprep. This is RFC 3439 principle of 
simplicity. I think Unicode is not RFC 3439 conformant, hence all our 
problems. Sure we need an IETF temporary patch, but we also need a 
sustainable long term solution. If we do not consider the later, IMHO 
we will not build a good enough patch.

jfc

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 24 Jul 2011 09:35:17 -0400

> Feedback is welcome. I'll provide a final version to the chairs before

Chairs and others,

I updated my slides on the plane yesterday. Reload that URL for the latest.

Peter

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