[65] in Open-Software-Foundation-News
DCE I18N WG's post-DCE 1.1 I18N requirements
daemon@ATHENA.MIT.EDU (kline_s@apollo.hp.com)
Fri Oct 28 19:04:18 1994
Resent-From: Bill Cattey <wdc@MIT.EDU>
Resent-To: osf-news-mtg@menelaus.LOCAL
From: kline_s@apollo.hp.com
To: sig-dce-i18n@osf.org, sig-international@osf.org
Cc: sig-dce@osf.org
Date: Fri, 28 Oct 94 16:11:39 -0400
SIG-ers,
Attached below is the final revision of the OSF DCE I18N Working Group's
prioritization of post-DCE 1.1 I18N requirements. The voting results
presented in this paper will be discussed at the OSF I18N SIG meeting,
which is being held on Wednesday (2nd November) of next week's SuperSIG
session.
Regards,
- Sue
+-----------------------------------------------------------------------+
| -- 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 |
+-----------------------------------------------------------------------+
===========================================================================
OSF DCE I18N Working Group's Post-DCE 1.1 I18N Requirements
October 28, 1994
Editor: Sue Kline (kline_s@apollo.hp.com)
Hewlett-Packard Company
The OSF DCE I18N Working Group recently concluded member prioritization of
DCE I18N requirements for post DCE 1.1 releases. The results of this
effort are presented here.
The following OSF member companies participated in the prioritization
process:
Digital
Hewlett-Packard
IBM
Tandem
The remainder of this document is broken into the following sections:
Background of Prioritization Weighting - discusses the procedure
used in applying prioritization values for the requirements.
Summary of Member Prioritization - presents the summary of the
requirements' prioritization.
Interpretation Comments - discusses "fuzzy" areas where members
had differences in their interpretation of requirement(s).
Member Company's Casted Vote - includes each actual individual
member company's requirement prioritization vote.
Background and Descriptions of Requirement - is the list of I18N
requirements from which member companies cast their vote.
Background of Prioritization Weighting
======================================
Up to 8 requirements were accepted for prioritization from each member
company. Weighting values were then used ranging from 8 to 0, where
the weight value 8 was applied to the highest prioritized requirement
and the subsequent descending values (7 through 1) applied to the
remaining requirements. Those requirements which were not prioritized
by a member company were assigned a weight value of 0.
Thus, the higher the weight value a given requirement received, the
higher the requirement's prioritization as concluded by the SIG.
As an example: if 2 member companies voted requirement X as their
highest requirement, and 1 other member company voted requirement X
as their second highest requirement, requirement X would have
a weighting of 23 (8 + 8 + 7). In contrast, if requirement Y only
received the second highest requirement from one member company and
no votes from other member companies, it would only have a weighting
of 7. Thus as determined by the SIG, requirement X obviously has a
higher prioritization than requirement Y - (23 - 7).
Summary of Member Prioritization
================================
Note: Weighted values preceded by an asterix (*) indicate some
difference in the interpretation of the requirement which influenced
member voting. These interpretation differences will be covered in
more detail in the next section "Interpretation Comments".
Note: Letters within parenthesis reference the actual requirement.
The full list of requirements is provided later in this document in
the section entitled "Background and Descriptions of Requirements".
Weight
Value Requirement description
------ -----------------------
* 27 [a] Implementation of X/Open's DIS (Distributed I18N Services).
24 [c] DCE Security support for I18N aliasing of principal names.
* 20 [g] Unrestricted character use in the DCE namespaces: CDS, GDS,
DFS.
19 [d] CDS support for I18N aliasing of principal names.
17 [b] Standardized "locale object", specified to satisfy X/Open DIS.
* 16 [f] Distributed message catalogs.
7 [h] DFS general I18N support.
* 5 [i + l] RPC support for ISO-10646 as an interchange format and/or
data type.
Interpretation Comments
========================
* 27 [a] Implementation of X/Open's DIS (Distributed I18N Services).
IBM and Tandem voted for the full implementation of the X/Open DIS.
Digitial only voted in favor of implementation of the "netspec"
portion of the DIS provided within DCE. This portion would
specifically utilize the DCE RPC services.
HP indicated their rationale for their low prioritization of this
requirement was that HP felt that this requirement was not achievable
in the DCE 1.2 timeframe, given the X/Open spec was still in Draft form.
* 20 [g] Unrestricted character use in the DCE namespaces: CDS, GDS,
DFS.
At the last DCE SIG meeting, HP agreed with other member companies
that this requirement is similar to requirement [g], and hence within
the prioritization tally, this requirement is included with
requirement [g] (Unrestricted character use in the DCE namespaces).
* 16 [f] Distributed message catalogs.
There was some difference in opinion about the implication of this
requirement. Some member companies believed that this requirement
would be fulfilled as part of providing the X/Open DIS. Another
member company indicated that this is specifically needed for DCE
to alleviate global scalability concerns brought about by DCE
localization.
Note: In the interim between the last DCE SIG meeting and the
publication of this document, the X/Open XoJIG (I18N) WG decided
that distributed messaging would not be addressed as part of the DIS.
* 5 [i + l] RPC support for ISO-10646 as an interchange format and/or
data type.
At the last DCE SIG meeting, it was agreed to fold requirements
[i] (IDL datatype to directly support UNICODE) and [l] (DCE RPC
supports ISO 10646 as interchange format) into a single requirement
given the relative similarity between the requirements.
Member Company's Casted Vote
============================
Below are the prioritized I18N requirements for DCE in the post 1.1
timeframe as received from Digital, HP, IBM and Tandem.
Digital's priorities (Jurgen Bettels):
1. Implementation of X/Open DIS (Note: "Netspec" portion only) [a]
2. Unrestricted character use in DCE namespaces: CDS, GDS, DFS
(Note: Modeled on X.500 UniversalString type) [g]
3. CDS support for I18N aliasing of principal names (Note:
Using the X.500 UniversalString type) [d]
4. DCE Security support for I18N aliasing of principal names [c]
5. DCE RPC supports ISO 10646 as interchange format [l]
6. Standardized "locale object", specified to satisfy X/Open DIS [b]
-------------------------------------------------------------------------
HP's priorities (Sue Kline):
1. DCE Security support for I18N aliasing of principal names [c]
2. CDS support for I18N aliasing of principal names [d]
3. GDS support of 1993 X.500 specification as re. I18N [e]
4. Distributed message catalogs [f]
5. DFS general I18N support [h]
6. Implementation of X/Open DIS [a]
-------------------------------------------------------------------------
IBM's priorities (Michael Kung):
1. Implementation of X/Open DIS [a]
2. Standardized "locale object", specified to satisfy X/Open DIS [b]
3. DCE Security support for I18N aliasing of principal names [c]
4. Distributed message catalogs [f]
5. Unrestricted character use in DCE namespaces: CDS, GDS, DFS [g]
6. DFS general I18N support [h]
7. CDS support for I18N aliasing of principal names [d]
8. IDL datatype to directly support UNICODE [i]
<Note: requirements below this point were not accepted. >
9. Localizable DCE command interface (CP) [j]
10. GDS support of 1993 X.500 specification as re. I18N [e]
11. DFS support for character encoding tags and encoding conversions
(assumes underlying OS support) [k]
-------------------------------------------------------------------------
Tandem's priorities (Motasim Najeeb)
1. Implementation of the X/Open Distributed I18N Services [a]
2. Locale object for the DIS [b]
3. Distributed message catalogs [f]
4. DCE security support for I18N aliasing of principal names [c]
5. CDS support for I18N aliasing of principal names [d]
6. Unrestricted character use in DCE namespaces [g]
Background and Descriptions of Requirements
===========================================
a. Implementation of X/Open's DIS (Distributed I18N Services):
Background:
This X/Open spec is currently in review draft stage is is scheduled
tentatively for final publication in late 1994/early 1995. It specifies
a set of interfaces which address particular problems in developing
distributed, global applications in the heterogeneous distributed
computing environment. These problems include the handling of locales
in both single and multi-threaded distributed processes (so-called "m_*"
proposal), as well as locale and/or codeset disparity between any number
of clients and a given server (so-called "Netspec" proposal).
Requirement:
DCE should support the implementation of this specification when it is
published.
=====
b. Standardized "locale object", specified to satisfy X/Open DIS
(Note: Deliberate vagueness here because the X/Open spec is still
in flux)
Background:
See also item a. The X/Open DIS does not specify the actual
implementation of the various "objects" described in the specification.
The further specification of the implementations of the objects is needed
to achieve multivendor interoperability.
Requirement:
DCE should specify and implement the various "objects" referred to
in the X/Open DIS.
=====
c. DCE Security support for I18N aliasing of principal names:
Background:
This is a continuation of the DCE 1.1 I18N requirement which specified
that internationalization support must be included in DCE. For DCE 1.1,
general I18N support was provided in the form of cleaning up the code to
use XPG/4 interfaces, removal of hardcoded ASCII logic and utilization
of message catalogs. In addition, a DCE codeset registry and RPC
enhancements were added to enable the identification and transmission of
data encoded in any codeset over the wire. For other DCE components to
support those I18N features which are unique to DCE, the 1.1 I18N RPC
and codeset registry support are base elements.
Requirement:
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 utilities such as dcecp will need enhancements.
=====
d. CDS support for I18N-ized aliasing of principals:
Background:
Same as requirement 'c', but for CDS.
Requirement:
Same as requirement 'c', but for CDS.
=====
e. GDS support of 1993 X.500 specification as re. I18N:
Background:
The current implementation of GDS only supports the 1989 version of the
X.500 specification. The 1993 version contains significant
modifications and enhancements required in the international
marketplace.
Requirement:
GDS should be enhanced to support the 1993 version of X.500
specification. In addition, it should be modified to recognize the full
repertoire of T.61 conversion algorithms.
=====
f. Distributed Message Catalogs
(Note: The definition of this item needs further work)
Background:
As part of deploying DCE into a global commercial environment, DCE's as
well as DCE applications' generated messages will be translated (ie.
localized) into a multitude of national languages and associated
codesets. In many cases, it will be important to offload the envisioned
large number of message catalogs off of small, light-weight clients and
store them into a server-based repository.
Requirement:
DCE should provide a generally available solution which would enable
message catalogs to be distributed onto server(s). This includes the
capability to access and retrieve messages over the network. Such a
capability must include provisions to account for national language and
codeset requirements of a given client. Such a solution must be
available to both DCE and DCE-based applications.
=====
g. Unrestricted character use in DCE namespaces: CDS, GDS, DFS
Background:
Currently the various namespaces accessible from DCE have various
restrictions as to what character encodings may be used in names,
and whether single or multibyte encodings are supported. In practice
this restricts names to ASCII if they are to appear in all three
namespaces, and does not allow the general support of non-ASCII filenames.
Requirement:
CDS, GDS, and DFS should allow names to be made up out of any single
or multi-byte character encoding supported on the underlying OS.
(Note: for GDS this overlaps with item 'e'.)
=====
h. DFS general I18N support
Background:
For DCE 1.1, all DCE components were expected to provide general I18N
support, such as using XPG/4 APIs and message catalogs, and also not
including any hardcoded ASCII logic. It was understood that DFS would
not be meeting this requirement, due to scheduling and resource
constraints.
Requirement:
DFS should be modified to address these general I18N concerns.
=====
i. IDL datatype to directly support UNICODE
Background:
UNICODE is a particular implementation of ISO 10646 which is specified
to be an unsigned 16-bit integer.
Requirement:
The IDL compiler should provide a datatype explicitly specified to
support UNICODE.
=====
j. Localizable DCE command interface (CP)
Background:
Currently the command-line interface for configuring DCE (CP) is not
internationalized, and so cannot be localized.
Requirement:
Internationalize the CP
=====
k. DFS support for character encoding tags and encoding conversions
(Note: The definition of this item needs further work. Should DFS be
modified to allow support of this ahead of OS support? This might be a
way to drive the tagging issue.)
Background:
Currently it is possible for data files (and even filenames) to be in
multiple encodings within a single (possibly distributed) filesystem.
While most current OS's do not provide explicit support for identifying
the encoding of a given file, there are plans to do this in the future.
It will be critical for DFS to provide support for this as well.
Requirement:
DFS should support the use of character encoding tags and encoding
conversions when possible and where appropriate.
=====
l. DCE RPC supports ISO 10646 as interchange format
Background:
While the existing DCE RPC provides a way for implementors to add
various kinds of codeset conversion modules and logic, none are provided
in the base implementation. ISO 10646 support would automatically
provide at least one way for a developer to design applications which
allow interoperability in a heterogeneous environment.
Requirement:
Explicit provision for the use of ISO 10646 as an interchange encoding
should be provided as part of the DCE RPC component. The conversions
themselves may be provided by "iconv", which is not part of the RPC
component, so some cross-functional coordination is needed.
