Subject: [drinks] on internationalization.

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 7 Sep 2011 17:21:02 +0200

One of the action items from the interim was to look at
Internationalization in SPPP. I've looked at the Internationalization
text from EPP, and have only found general text, eg. in Section 5 of RFC
5731:

http://tools.ietf.org/html/rfc5733#section-5

That section explains that since EPP is based on XML, native Unicode
support is included, and also has some text on time/date values.

However, there are no additional constraints in EPP regarding the
contents of any field in the protocol. That means that - unless i've
overlooked something - EPP object data can include arbitrary Unicode
characters. 

Repository object identifiers are, however, limited to "Word" characters
(using the XSD pattern facet limited to "\w" characters). The set of
characters that matches is pretty broad, though:

[#x0000-#x10FFFF]-[\p{P}\p{Z}\p{C}] (all characters except the set of
"punctuation", "separator" and "other" characters)

(from http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#dt-regex)

Therefore, to conclude, EPP allows for a broad range of characters in
identifiers, and since EPP has gone through IESG review successfully 3
times, i would suggest that we include a similiar "Internationalization
Considerations" section in the SPPP protocol document, and not try to
restrict fields more than EPP does.

comments are highly appreciated.

Alex

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Sep 2011 09:38:32 -0600

Here is a start at some discussion of the topic...

On 9/7/11 9:21 AM, Alexander Mayrhofer wrote:
> Internationalization in SPPP. 

First, what are you trying to achieve? Saying "internationalization" is
a bit like saying "security": it has many facets and often means
different things to different people.

> I've looked at the Internationalization

To be precise, UTF-8-encoded Unicode code points. :)

See http://tools.ietf.org/html/draft-ietf-appsawg-rfc3536bis-06 for a
helpful explanation of various i18n terms.

> identifiers, 

Earlier you talked about fields in the protocol, now you are talking
about identifiers. Do you care more about identifiers than any other
kind of field? Is there a distinction here? What do you *do* with these
various fields and identifiers? Do you, for example, compare them? If
so, for what purposes (authentication, authorization, etc.)? What are
the implications if a comparison operation yields a false positive or a
false negative?

See http://tools.ietf.org/html/draft-iab-identifier-comparison-00 for a
detailed discussion of these issues.

As to comparison of internationalized strings in application protocols,
please consult the work of the PRECIS WG to see if it is relevant here:

http://tools.ietf.org/html/draft-ietf-precis-problem-statement-03

http://tools.ietf.org/html/draft-ietf-precis-framework-00

If you are going to be comparing identifiers for purposes that have
security implications, then I think you will need to say something more
than "just use UTF-8".

> and since EPP has gone through IESG review successfully 3

What is the relationship between EPP and SPPP? Does SPPP essentially
emulate EPP? If so, it might make sense to re-use some text from the EPP
spec. On the other hand, it's possible that i18n issues were not really
addressed in the EPP spec (despite surviving IESG review three times)
and that you might want to think about these issues anew for SPPP.

HTH,

Peter

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

---

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 9 Sep 2011 15:27:38 +0200

> First, what are you trying to achieve? Saying "internationalization" is a bit like
> saying "security": it has many facets and often means different things to
> different people.

Peter, that's an excellent comment and comparison. I think the considerations are as follows:

- We have "data fields" and "identifiers" in the protocol:  "data fields" are just passed through the protocol / registry ("garbage in / garbage out" style), and "identifiers" need to be compared, eg. against parameters in commands, because they're used to identify objects that are provisioned.

- I understand (and agree) that modern IETF protocols should not be limited to pure ASCII.

- "data fields" are probably easy to internationalize, since the components handling the procotol do not need to examine their contents. However, there might be issues when such fields are displayed (for example, when LTR and RTL strings are mixed within a field) - are there any recommendations on text regarding such issues?

- "identifiers" are more complicated, because they're affected by all the obvious normalization / comparison issues. A quick win would be to restrict such fields to ASCII only, however, i understand that might be unacceptable from the Internationalization perspective.

[..]
> To be precise, UTF-8-encoded Unicode code points. :)

agreed - and, that's the option we would go for in SPPP as well.

> See http://tools.ietf.org/html/draft-ietf-appsawg-rfc3536bis-06 for a helpful
> explanation of various i18n terms.

Ah, thanks for the pointer - great!

[..]
> Earlier you talked about fields in the protocol, now you are talking about
> identifiers. Do you care more about identifiers than any other kind of field? Is
> there a distinction here? What do you *do* with these various fields and
> identifiers? Do you, for example, compare them? If so, for what purposes
> (authentication, authorization, etc.)? What are the implications if a
> comparison operation yields a false positive or a false negative?

As outlined above, i think the identifiers are the crucial part (which doesn't mean that other fields don't matter, but they're typically not used to identify objects). 

Comparison operations are important since those identifiers are used to identify relations between objects, and also "address" objects affected by a certain command. False positives and/or negatives could lead to loosing data integrity between objects, or commands affecting the wrong objects. 
 
> As to comparison of internationalized strings in application protocols, please
> consult the work of the PRECIS WG to see if it is relevant here:
> 
> If you are going to be comparing identifiers for purposes that have security
> implications, then I think you will need to say something more than "just use
> UTF-8".

I will look at the PRECIS work. 

> > and since EPP has gone through IESG review successfully 3 times, i
> > would suggest that we include a similiar "Internationalization
> addressed in the EPP spec (despite surviving IESG review three times) and
> that you might want to think about these issues anew for SPPP.

EPP and SPP serve similar purposes (provisioning objects in a "registry"), but serve different domains. SPPP is not an emulation of EPP, but has some similar properties. The impact of comparison operations on identifiers in EPP is similar to those in SPPP, which is why i was looking for respective text in those RFCs.

Alex