[92] in Open-Software-Foundation-News
I18N Comments on RFC 63.0
daemon@ATHENA.MIT.EDU (kline_s@apollo.hp.com)
Fri Nov 18 20:14:02 1994
Resent-From: Bill Cattey <wdc@MIT.EDU>
Resent-To: osf-news-mtg@menelaus.LOCAL
From: kline_s@apollo.hp.com
To: dce-1.2-comments@osf.org
Cc: sig-international@osf.org, sig-dce@osf.org
Date: Fri, 18 Nov 94 18:02:03 -0500
At the last I18N SIG meeting, the results of the member prioritization of
the post DCE 1.1 I18N requirements were discussed. A primary agenda item
of the meeting was to come to closure on those requirements which the SIG
felt must be included in the DCE 1.2 release and as a subsequent action,
provide those identified "MUST" I18N requirements as commentary to
RFC 63.0.
In fulfillment of this action item on behalf of the I18N SIG, I am now
forwarding the following list of SIG identified "MUST" I18N requirements
as comments for RFC 63.0 and request that consideration is made for their
inclusion in the DCE 1.2 release.
Regards,
- Sue Kline
DCE I18N sub-WG SIG co-chair
Background:
The DCE 1.1 release fulfilled many of the basic I18N requirements which
are common to nearly all open systems based software technologies.
However, outside of the RPC I18N extensions which were provided in
DCE 1.1, DCE currently does not address many I18N concerns that are
uniquely endemic to DCE's various components. The I18N SIG's expectation
has been that those DCE technology specific issues would be addressed
in subsequent (post-DCE 1.1) releases.
The following requirements have been identified by the I18N SIG as
"MUST" requirements for DCE 1.2. The SIG's rationale in identifying
these as "MUST" requirements was that these were viewed as major
inhibitors precluding the successful global deployment of DCE.
- DCE Security support for the I18N aliasing of principals
This requirement specifies that support is needed within the DCE Security
component to enable the specification, processing, and lookup of principal
aliases which are encoded in codesets other than DCE PCS (~7-bit ASCII).
In addition, front-end client utilities such as dcecp will require
enhancements to manipulate and access such principal aliases.
This support would enable principals (e.g. user, group and organization
names and file names) in the form of an alias to be representable in a
local codeset. The requirement would ensure that principals can be
stored within the Security registry in a representation that ensures
successful client access via local language conventions, as well as
no data loss. The preferred implementation method in fulfilling this
requirement would be through the addition of a/(set of) well-known
extended registry attribute(s) (ERAs) within the Security server which
utilize the RPC I18N code set converter extensions added in the DCE 1.1
release.
Such support has been identified by the I18N SIG as being critical
for the successful global deployment of DCE. Single sign-on, in particular
within the single user/system (PC) client realm, will not be achievable
without this support. PC's, such as OS/2 and NT Windows, are localized for
a particular geographic market where the expectation is for complete
local language support for a given user, including the logon phase.
In addition, I18N principal aliasing is critical to disambiguate
principals in a worldwide setting where transforming names to an
ASCII-fied form results either in principal name ambiguity or in a
culturally unacceptable representation of a principal name. The former
case is highly likely in cultures which use an ideographic language.
(A very simple English example of this ambiguity is where names "two",
"to" and "too" would all be mapped phonetically mapped to "two".)
The latter case is possible in all cultures where diacritical marks
(e.g. accents) have a profound influence on a given string's meaning.
- Unrestricted character use in all DCE namespaces
This encompassing namespace requirement is similarly critical for
the global acceptance of DCE. DCE must be able to access any file
within the namespace, regardless of its local encoding.
This requirement is broken down into the 3 affected DCE component areas:
a. XFN / CDS
The I18N SIG recognized XFN as a viable alternative to recommending I18N
extensions to CDS and a requirement which is achievable in the DCE 1.2
timeframe. XFN already has a fairly well defined repertoire of APIs
which take into account I18N naming issues. Hence, the I18N SIG would
expect that all I18N features would be fully enabled in the implementation
of XFN as currently scoped for DCE 1.2. The I18N SIG's only specific
requirement is that XFN provides full I18N support for all character
data representations - portable, canonical, and tagged.
b. X.500 / GDS
The I18N SIG advocates that GDS move forward in its support of the X.500
specification to supporting the 1993 version, which includes significant
modifications and enhancements for the international marketplace. As part
of this requirement, the I18N SIG encourages allowing the usage of the
"UniversalString" type as described in the 1993 version of the X.500
specification and explicitly discourages further usage of T.61 as GDS's
network transmission encoding for DCE 1.2.
c. DFS
The I18N SIG believes that DFS currently does not preclude the transmission
of character data of any encoding representation. Hence, for the DCE 1.2
release, the I18N SIG is requesting formal verification and advertisement
of this support for the DCE 1.2 timeframe.
Lastly as a point of record, the I18N SIG had also listed "Implementation
of X/Open's DIS (Distributed I18N Services) specification" as a MUST
DCE 1.2 requirement. However, upon discussion amongst SIG members,
it was decided that this requirement will be taken on as a work item for
a separate to-be-formed I18N PST. Hence, this requirement is not formally
included in the I18N SIG's requirements for the DCE 1.2 release.
+-----------------------------------------------------------------------+
| -- Sue Kline Hewlett-Packard Company |
| DCE Core Technology tel: +1 508 436 4960 |
| Open Systems Software Division HP Telnet: 436-4960 |
| email: kline_s@apollo.hp.com fax: +1 508 436 5140 |
+-----------------------------------------------------------------------+
