--Apple-Mail-76-165318432
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed


On Nov 17, 2004, at 7:57 PM, MINOURA Makoto wrote:

>  - Mountpoints
>     (/<Russion dirname>/<Japanese dirname>/<German filename>,
>      but this could not be accessible from processes with
>      LC_ALL=de_DE.ISO8859-15 for example)

I think this could be handled if UTF-8 were the standard encoding for 
userland<->kernel interaction, yes?

>  - Multiple encoding in a single volume
>     (which we allow currently; suppose /home for Russians
>      and Japanese, and /home on a UFS)

I think UTF-8 could also handle this, which is great because it doesn't 
require any changes to the UFS on-disk representation.

>  - Msdosfs, shortnames in legacy encoding and longnames in UCS2

Again, UTF-8 could handle this.

My feeling is that the convergence point should be "UTF-8 at the system 
call layer", i.e. userland gives UTF-8 names to the kernel, the kernel 
gives UTF-8 names to userland.  It would then be the responsibility of 
the individual applications/system libraries/kernel subsystems to do 
whatever translation to/from UTF-8 is required.

         -- Jason R. Thorpe <thorpej@shagadelic.org>


--Apple-Mail-76-165318432
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQFBnhTuOpVKkaBm8XkRAsjFAJ93ZAVUgb/zzJ48PdZ4iS4ynE9yPQCeLfgu
jJhHQ8vZEo8of6lZdWm0s0c=
=MbJq
-----END PGP SIGNATURE-----

--Apple-Mail-76-165318432--