On Mon, Mar 12, 2012 at 6:41 PM, Sam Hartman <[email protected]> wrote: >>>>>> "Cantor," == Cantor, Scott <[email protected]> writes: > > Cantor,> I'm working with an absence of understanding of exactly how > Cantor,> the display form would be used, but my experience with XML > Cantor,> data in general is that sticking with UTF-8 where possible > Cantor,> tends to keep things simpler, since an application can > Cantor,> always do whatever converting it wants to from that > Cantor,> baseline. > > > Me too. > I'm not really sure what you'd do with the display form other than dump > into a debug log. > > I was hoping to get input from those who added the display form to the > API.
I did that. It was in the original. It was intended for tools like, say, a GSS version of klist (hand waiving). Now, the GSS-API specifies somewhere that it deals in Latin-1. Clearly we're NOT going to have consensus on using Latin-1 as that's just ridiculous. UTF-8 would certainly be a lot better than "unspecified" or "Latin-1", but I think in practice applications that care for display forms of attribute values will want something that is in the current locale's codeset. I'd be OK with saying these must be UTF-8, and I'd be OK with saying these must be in the application's locale's codeset. Applications that need to send these display forms over the wire (e.g., in log messages) will want UTF-8. Applications displaying these in UIs will want the current locale's codeset. In the interest of speeding a consensus I'll go with UTF-8. Nico -- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
