[Ietf-not43] l10n/i18n issues

[Eric A. Hall]

on 2/6/2003 12:16 PM Andrew Newton wrote:
> Eric A. Hall wrote:
> 
>>The major problem that this introduces for me is that I can no longer
>>simply reuse the inetOrgPerson schema. This is okay from a work POV but
>>its undesirable from an LDAP directory POV.
> 
> I take this to mean that it is doable but just not the purist approach. 
>   Correct?

Sort of. The underlying long-term value benefit to the LDAP-WHOIS model is
that it provides a baseline directory of Internet resources that other
applications can build on. But if the service itself can't use (and
therefore cannot provide) the inetOrgPerson schema for other applications
to leverage, then this is a huge gap in the benefit. That's a bit worse
than just sacrificing purity.

One potential workaround is to continue using inetOrgPerson for the
internationalized data, and provide an auxillary object class for the
ASCII contact data. That would allow other applications to use
inetOrgPerson in its pure form, while also satisfying the CRISP
requirement that seems to be developing. However, these two interests
don't necessarily mesh cleanly, so this wouldn't be a great solution for
either of them. For example, an LDAP focus would favor the
internationalized contact data over the ASCII data (we'd want to ensure
that inetOrgPerson tended to have the data), while a CRISP focus would
reverse the weighting (the word MUST has been used...).

There are also some issues with satisfying language tagging requirements
in this kind of model.

> Some proposed text:
> 
> The schema for the contact data set MUST be able to contain an 
> identifier indicating the language used for the contact data.  The 
> protocol MUST allow multiple representations of a contact specified by 
> the language identifier.

I think we need to itemize a lot of different areas, and even in this
particular instance we are really talking about unstructured free text in
general (these rules also need to apply to comment blocks, for example),
and a particular subset of contact data.

Also, the 2277 MUST rules apply to charset and language equally.

Maybe something like:

Z.n The service MUST conform to RFC 2277 rules regarding textual data. In
particular, the protocol and/or schema MUST be able to indicate the
charset and language in use with unstructured textual data.

Z.m The service MUST be able to support multiple representations of
contact data, with these representations complying with the requirements
in section Z.n. The service SHOULD be able to provide non-ASCII contact
data in its natural form as well as in US-ASCII.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/