Subject: [drinks] Internationalization Update

From: Alexander Mayrhofer <[email-masked]>
Date: Thu, 17 Nov 2011 10:17:46 +0100

All,

one of the open issues of SPPP is updating Internationalization
considerations. For a background of the issue, please read the following
earlier thread:

http://www.ietf.org/mail-archive/web/drinks/current/msg01024.html

I met with Peter Saint-Andre, Robert Sparks and Pete Resnick, and we hab
a brief, but very productive discussion. I explained that we have
concerns about two different types of elements in our protocol:

- Elements that are simple "garbage in", "garbage out" (or "Blobs").
These elements serve as "data container" and the contents of these
elements is not tied to any semantics in the protocol. An example of
such an element is the "sourceIdentLabel".

- Elements that serve as identifiers: Since those elements are used to
identify object instances, they have semantics attached to their values,
and need eg. be compared. An example of such an element is the "dgName"

For the "simple" elements, there was agreement that no special
considerations need to be applied. If comparison of such elements is
ever to be done, then it would be bytewise comparison.

I clarified that we have already restricted most elements to the XML
"token" schema definition.

For the "identifier" elements:

Pete Resnick asked me a few questions to narrow the issue down (my
answer in parentheses, i hope i remembered all of them correctly):

- Q: Are the elements machine-generated? A: No, could be created by
provisioning staff.
- Q: Are they going to be displayed to users? A: Yes, could be that
provisioning staff reads them.
- Q: Do we want to allow whitespace in those identifiers? A: No, we
don't need whitespace (Personal decision, any objections?)
- Q: Do we need "similar looking" characters, such as the japanese
"ASCII-equivalent"-Characters eg. match the respective ASCII characters?
In other words, are we fine with some false negatives? A: Yes, we are
fine with false negatives in comparison operations in such cases.
- Do we want the elements to be case sensitive? A: Not sure, probably.

We continued the discussion with my assumption that we would need to
choose a Stringprep profile, and apply that in the propoer positions in
the data flow. However, Pete noted that we would probably not need
Stringprep in the first place, but one of the Unicode normalization
function would be sufficient. The recommended method would be NFC
(Normalization Form C). 

If we want the elements to be case insensitive, we could alsp require
the Unicode operation toLower applied.

>From my perspective, the next step would be to decide at which point
those normalizations need to be applied (Client? Server?). Maybe we can
briefly discuss this in the WG session on friday, and subsequently
create actual text.

Alex

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 17 Nov 2011 18:03:37 +0800

On 11/17/11 5:34 PM, Pete Resnick wrote:
> On 11/17/11 5:17 PM, Alexander Mayrhofer wrote:
> If you let me know approximately when this might appear on the agenda,
> I'll be there. At the very least, I'll make sure to be in Jabber and you
> can give me a heads-up when the topic is starting.

I'll be in the CORE WG session at that time, so unable to join.

Peter

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

---

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 18 Nov 2011 02:59:03 +0100

> If you let me know approximately when this might appear on the agenda,
I'll
> be there. At the very least, I'll make sure to be in Jabber and you
can give me
> a heads-up when the topic is starting.

Pete,

sorry for the late notice. We will only make use of the first meeting
slot for DRINKS (11:20 - 12:20), and we will discuss i18n at the end of
the "Protocol" agenda item. This should come up shortly before noon
(it's on the last slide of the "Protocol" slide deck, which is scheduled
for between 11:40 and 11:55). 

Would be great if you can make it. We will definitely give you a heads
up in Jabber.

Alex