[pp-xml] ICE Part 1 (Security & Internationalization)

Nick Lothian Lothian.Nicholas at lmsol.com.au
Thu Apr 27 06:19:54 CEST 2000


I'm reading through the ICE document (http://www.w3.org/TR/NOTE-ice), to see
what we can use.

Here's some stuff that addresses some issues we've spent time talking about
in the past. I think they have come to basically the same conclusions as us.

Nick


1.4.4 Security
The ICE protocol itself deliberately does not address security, because the
required levels of security can be achieved via existing and emerging
Internet/Web security mechanisms.

In the specific case of digital signatures, non-repudiation, and similar
concepts, two things have happened that have steered the Authoring Group
away from the notion of having digital signatures inside ICE itself:

Separate efforts are underway to define digital signing standards for XML
documents. The ICE Authoring Group felt that duplicating such work within
ICE was not warranted.
Defining digital signing standards for XML documents is quite tricky, and
requires defining a canonical text representation of the documents (because
the digital hash functions hash the textual representation of a document,
not its logical representation). The ICE Authoring Group did not want to
define their own, possibly conflicting, canonical representation rules to
solve this problem.

**********

1.5 Internationalization Issues
Few internationalization issues occur at the protocol level at which ICE
operates, but four specific issues are worthy of note:

Support for International Character Sets.
ICE itself defines no specific mechanisms for encoding or identifying
character sets. Instead, ICE relies on capabilities in XML for encoding and
supporting international character sets.

Protocol Error Message Text.
 The error messages in an ice-code (see 3.3) include both a numeric error
code and a short phrase, such as "OK" or "Not found". As is described in
detail in 3.3.4, the phrase is intended for informational purposes only; it
is the numeric error code itself that defines the semantics of the error
message. Internationalized implementations of ICE are expected to convert
the numeric ICE error code into an appropriate presentation string in the
local language. Thus, there is no requirement for ICE to support
multi-lingual versions of the error code phrase, such as "Mahalo" instead of
"OK" in the 200 code.

Other Protocol Text Strings.
 The ICE protocol sometimes uses string values as semantic identifiers. For
example, an ice-sender (see 3.5.1) encodes the sender's role as either
"subscriber" or "syndicator". These textual strings are intended as
arbitrary tokens representing a specific concept; they are not intended for
presentation and thus have no impact on internationalization issues.
Language identifier for textual data. Some ICE elements and attributes are
specifically designed for the transport of textual data intended for use by
humans. For example, the ice-business-term element (see 4.3.1). ICE provides
a lang attribute in all places where human-readable text is being
transported and might require an identification of its specific language
encoding. When used, the lang attribute SHOULD be filled in according to
standards RFC-1766 (Tags for the Identification of Languages) and ISO-639
(Code for the representation of names of languages).








More information about the Peerpress-xml mailing list