Hi Ira!
> SLP is 'Service Location Protocol'. SLPv2 Protocol is RFC 2608.
> It is widely used for locating printers, file servers, etc.
> It is also the basis of storage server discovery in the new IETF
> IPS iSCSI (SCSI over IP) Internet-based storage system I-Ds.
>
> The cogent point about the use of NFKC in SLP is that it's
> been recommended to us (SLP folks) for use in _all_ string
> comparisons of SLP-registered 'service attributes', which may
> be URLs or may be any other string data. Perhaps that's
> reasonable for string comparisons (probably better than NFC)?
>
> Since SLP borrows string comparison filters from LDAPv3, the
> strings are further case-folded to allow case-insensitive
> string comparisons (there is some controversy over this).
If one does case folding (in some way; this is non-trivial!), then
some NFKC-like process should be used in conjunction with that
(as planned for IDNs, internationalised domain names).
> But in filenames (e.g., pathname parts of URLs) NFKC seems like
> a very poor choice, because it loses information for mapping
> back to local legacy charsets, right?
I would tend to agree. Most file systems (including NTFS!) are
case sensitive, and "compatibility sensitive" too.
To be nitpicking, as of yet very few file systems do any
normalisation (UFS being an exception), and any normalisation
looses full roundtrip preservation. So for most file systems
even NFC may be causing (rarely) loss of file name lookup.
Kind regards
/kent k
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
