[Ietf-not43] l10n/i18n issues

[Rick Wesson]

Eric,

Our requirements don't contain anything about formatting for delivery. We
do tag the elements though the description centric to the USA. While the
UPU encourages that a postal address be in local script AND roman scripts
the UPU only publishes 8bit ASCII data.

I propose that we have a 7bit ascii representation and a UTF-8
representation that MAY be used, butf the 7bit ascii representation is
REQUIRED.

kinda like we did in EPP.

-rick


On Wed, 5 Feb 2003, Eric A. Hall wrote:

>
> on 2/5/2003 12:28 PM Eric A. Hall wrote:
>
> >     Is a reasonable compromise position that things like
> >     contact information MUST be provided in a format which is
> >     compliant with international postal regulations? Would
> >     that be sufficient? Does anybody know what they are?
>
> Couple of useful links:
>
>   http://www.upu.int/post_code/en/international_addressing.shtml
>
>   http://www.columbia.edu/kermit/postal.html
>
> General consensus is that all elements of an address should be used in the
> native language/script of the recipient (the contact person), while the
> destination country and zone information should also be provided in a form
> which the originator country can handle.
>
> In general then, I would think that the proper policy would be for contact
> information to allow any language/charset, with two clarifications. First
> is that country data must be tokenized, and second is that the remaining
> elements MUST have language identifiers and MUST also pass the necessary
> charset information (note that ~"MUST be provided in UTF-8" is a suitable
> instance of this). This should allow for localization on the client side.
>
> --
> Eric A. Hall                                        http://www.ehsco.com/
> Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
>
> _______________________________________________
> Ietf-not43 mailing list
> Ietf-not43@lists.verisignlabs.com
> http://lists.verisignlabs.com/mailman/listinfo/ietf-not43
>