Subject: [drinks] Updated "internationalization & comparison" proposal.

From: "Alexander Mayrhofer" <[email-masked]>
Date: Wed, 29 Feb 2012 12:08:24 +0100

Hi,

in light of my action item AI-17 (see design team meeting minutes),
here's an updated proposal regarding internationalization and
comparison.

(I do propose to add the "Internationalization" section between section
8 and 9 (XML/Security cons) of the framework document - i think we can
keep it reasonably short):

--- snip ---
9. Internationalization

Character encodings to be used for SPPF elements are described in
Section 8. The use of time values
in the protocol is specified in Section 3.2. Where human-readable
languages are used in the protocol,
those messages SHOULD be tagged according to RFC 4646, and the transport
protocol MUST support
a respective mechanism to transmit such tags together with those
human-readable messages. 
If tags are absent, the language of the message defaults to "en"
(English).
--- snip ---

For the "comparison" discussion, i suggest to add the following text as
a new sub-section to section 5 of the framework document (for example,
between current 5.2 and 5.3):

--- snip ---
5.3 Comparison Operations

The protocol contains two categories of elements. The first category,
called "blobs" for the purpose of this document, 
contains data that is transported by means of that protocol, but is
neither used to identify objects, or to refer
between objects. The other category is called "identifier", and is
either used to address an object, or to refer between
objects.

The following elements are "identifiers":

  * rant
  * rar
  * dgName
  * rgName
  * egrRteName

All other elements contained in the protocol fall under the "blobs"
category. For "identifiers", the following rules apply:

  * Identifiers are case insensitive, and MUST use Unicode Normalization
Form C (NFC) in comparison and mapping operations
  * Identifiers MUST be limited to contain characters from the following
Unicode General Categories only: Lu, Ll, Lm, Lo, Mn, Mc, Me, Nd, Nl, No,
Pc, Pd, Ps, Pe, Pi, Pf, Po, Zs
  * The Registry MUST store such identifiers in their lower case
mapping, and MUST correctly map upper case representations of
identifiers to their lower case equivalent in comparison operations
  * Clients SHOULD lowercase identifiers before sending them to the
Registry.

If elements of the "blob" category are ever to be compared, byte-wise
comparison MUST be used.
--- snip ---

(Note: Since i am not a unicode expert, the list of Character Categories
might need some review...)

Please comment on the new proposal.

Alex