- From: Jacob Palme <jpalme@dsv.su.se>
- Date: Sun, 4 Apr 1999 18:07:57 +0200
- To: IETF Applications Area Discussion List <discuss@apps.ietf.org>, SeniorOnline technical mailing list <sol-tech@ambra.omega.it>
I am involved in an EU-funded project Senior Online
(http://cmc.dsv.su.se/sol/) which aims at making the
Internet more suitable for elderly people. As part of this
project, we are to develop groupware systems and
portal/directory systems. We are just now at the stage
where we are to start specifying the protocols to be used
(a) between two groupware systems, (b) between groupware
systems and portal/directory systems.
The protocols, which we define, may in the future be
submitted as standards proposals in IETF. We will start
implementing them based on two groupware systems under
development, KOM 2000 (http://cmc.dsv.su.se/KOM2000/) and
Web for Groups (http://www.webforus.com/). We are
interested in getting other groupware vendors to try our
protocols, for example First Class
(http://www.business.softarc.com/works/index.shtml) and
Lotus Notes/Domino (http://www.lotus.com/).
One important issue, when starting applications area
protocol development, is the choice of coding method. I
have written an overview of the alternatives with their
advantages and drawbacks. Please give input with comments
on this table and on which choices to recommend.
Here is the overview:
--- --- cut here --- ---
Choice of Coding Format for Senior Online
=========================================
An important, and difficult, choice is the selection of coding
format and base web protocol for the communication between servers
in Senior Online. Two major such types of communication are
envisaged:
(1) The protocol for communication between groupware servers
(2) The protocol for communication between groupware servers and
portal servers
Here is a short description of the choices:
Coding format choices:
---------------------
Note: Some of these formats can be combined. For example, the e-mail
formats can be used for coding of the actual text of messages,
combined with the other formats for other information.
Format Description
------ -----------
MIME The standard format for complex e-mail messages,
where the body can be split recursively into
multiple body parts.
MFORM = Multipart/formdata Variant of MIME, one of the formats used, when a
web user fills in a form in a web page and pushes
the SEND button.
MHTML = Variant of MIME, the commonly used format for
Multipart/alternative, sending HTML-formatted messages via e-mail. Used
Text/html and by KOM 2000 when sending
messages from KOM 2000 to
Multipart/related e-mail. (? Web for Groups probably also uses this
format in communication with e-mail?)
XML A currently very popular format, strongly
supported by IBM and Microsoft, for sending
structured information on the Internet. Good for
complex structures, not so good for binary
information (like pictures or attachments)
ASN.1 A complex and powerful binary format, used by
LDAP.
LDAP The currently most popular format for
communication with directory systems. Good for
complex structures and for distributed directory
data bases. Uses ASN.1.
LDIF A variant of LDAP with
textual, instead of binary,
encoding.
RFC822 header format A simple format common in many protocols,
including e-mail headers and HTTP headers.
Corba A "remote procedure call" protocol for
communication between program modules on
different servers, written in common
programming languages.
As an aid in selecting this format, here is a table of choices and
their pros and cons. Question marks indicate that I do not know or
am not sure.
Format: MFORM MIME XML LDAP LDIF RFC822 Corba
------ ----- ---- --- ---- ---- ------ -----
Easy to Very Yes (4) Yes (4) Bad (1) Yes (4) Very Yes (4)
produce much much
manually and (5) (5)
debug
Ease of OK (3) OK (3) OK (3) Diffi OK (3) Easy Very
coding cult (4) easy
(1) (5)
Portability Good Good Good Good Good Good Bad (1)
(4) (4) (4) (4) (4) (4)
Binary data Good Good No (1) ? (3) ? (3) No (3) Yes?
(4) (4) (4)
Acceptabi Good Good Very Very Good Good Bad (1)
lity as a (4) (4) good good (4) (4)
future (5) (5)
standard
Ease of OK (3) OK (3) Good Good Good Good Good?
specifica (4) (4) (4) (4) (4)
tion
Total score 23 22 21 18 22 25 19
Recommendation: I suggest that we start with the RFC822 header format,
combined with MIME for the format of messages.
Protocol format choice:
----------------------
Possible choices for the protocol (to be extended for our needs):
Choice SMTP HTTP Corba
Description The Internet e- The WWW protocol, A remote
mail format, based on direct procedure call
based on store- connections, method, popular
and-forward of popular as a base in the telecom
messages. for new industry.
protocols.
Advantage Good for sending Easy to use, Easy to use.
messages, we have popular.
to implement it
anyway in order
to handle e-mail
connectivity,
built-in queing
and resending
facility when the
destination
server is down.
Disadvantage Store and forward Complex, but you Limited platform
means that you can choose a availability, not
get no direct subset suitable acceptable for a
responses to for your needs. standard
queries. protocol.
Recommendation: I suggest we use HTTP for all communication except
the sending of messages. For the sending of messages, I am not sure
whether to recommend SMTP or HTTP.
Character set format choices
----------------------------
Choice ISO Latin 1 Charset UTF-7, UTF-8
------ ----------- ------- ------------
Description ISO 8859-1 Several, with UTF-7, UTF-8
standard charset parameter encodings of
Unicode/ISO 10646
Advantage Easy to use The format used
Expected to be what
today in web and e- all computers use
mail in the future, but
not yet well
supported by all
platforms
Disadvantage Only good for Difficult to Some debugging
Western European implement,
problems because it
languages (not, for especially for the is not well
example, Polish, search engine supported by
Hungarian, Cyrillic, existing protocol
Arabic, Hebrew, debugging software
Asian languages) like telnet and
text editors
UTF-7 and UTF-8 are encodings of the future character set standards
Univode and ISO 10646. These encodings of Unicode/ISO 10646 are
especially suitable for Internet protocols, because all Latin letters
and digits and some common punctuation characters are the same as in
ASCII. IETF recommends UTF-8. The only advantage with UTF-7 is that
it can be sent without further encoding in e-mail.
Recommendation: I recommend that we start with the Charset choice,
but only using one charset, ISO Latin 1. This can in the future be
extended to either full Charset or Charset with a choice between
ISO Latin 1 and UTF-7 or UTF-8.
------------------------------------------------------------------------
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme
Received on Sunday, 4 April 1999 12:08:57 UTC