[Ietf-not43] l10n/i18n issues

[Andrew Newton]

Eric A. Hall wrote:
> 
>  1) Attribute identifiers need to capable of being converted into
>     a language/charset of the client user's choosing. EG, something
>     like the "abuse contact" output identifier should be able to be
>     converted into something other than English, as should search
>     input. I don't think this is a problem with either of the
>     current proposals -- both of them should allow the client to
>     convert attribute identifiers locally without imposing
>     additional protocol overhead or without breaking subsequent
>     queries -- but I strongly believe that this should be a formal
>     requirement anyway.

I'd like to add this to 3.1.3 to make it clearer:

   The client-to-server protocol must define a standard set of
   data structures or schemas to be used when exchanging information.
   It must also posses the ability to allow for the use of newer
   data structures that are currently nor foreseen by this specification.
   In both cases, the description and specification of both types of
   data structures or schemas must be done in the same way (i.e. the
   same schema language).

   The schemas must also be capable of "tagging" data with a unique
   idenitifier.  This identifier can then be used to localize the name
   of that type of data.  For instance, a piece of data may have the
   value "Bob" and its type identified with the number "5.1".  Client
   software could use this to display "Name: Bob" in an English
   locale or "Nombre: Bob" in a Spanish locale.

Note that 3.1.3 already has some MUST/SHOULD language... this would just 
be in addition to what is there.

>  2) Certain units of measure in attribute data needs to allow
>     for client-side localization (dates and timestamps are the
>     obvious elements). As with attribute identifiers, I believe
>     this should also be spelled out with a formal requirement,
>     but I'm not sure of the degree (see the following items).

Anything much beyond dates and timestamps would probably be a big time 
pit.  Plus, I don't think we need to do anything beyond that anyway. 
Everything else should just fall back to the support of the schema language.

>  4) Issues with certain kinds of structured data are also a
>     concern (domain names, email addresses, etc), but since
>     those attributes are structured they are a lot easier to
>     deal with and have pretty much been figured out. However,
>     there is still a need for a requirement for proposals to
>     explicitly spell out how and where these attribute values
>     will be transformed.

What do you mean by "transformed"?  I'm not sure why an email address 
would need to be transformed.

-andy