LISTSERV mailing list manager LISTSERV 15.5

Help for MHTML Archives


MHTML Archives

MHTML Archives


View:

Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font

Options:

Join or Leave MHTML
Reply | Post New Message
Search Archives


Subject: Re: Web Week: MHTML questions
From: Jacob Palme <[log in to unmask]>
Reply-To:IETF working group on HTML in e-mail <[log in to unmask]>
Date:Sat, 23 Aug 1997 19:25:25 +0200
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (127 lines)


Here are some additional comments. I am one of the two editors of
the standard.

At 12.48 -0700 97-08-21, Einar Stefferud wrote:
> >Todd Spangler wrote Thu, 21 Aug 1997 11:57:53 -0400:
> }
> }* The WG was supposed to be "inactive" during the vendor-implementation
> }period. What were the problems that required further work from the group in
> }Munich? What was accomplished there?
> }
The most important problems discussed during the Munich meeting were

(a) What should a mailer do if it is asked to send certain kinds of incorrect
HTML documents (not correct according to the HTML standards). Such
inocrrect document will probably seldom appear when they were produced by
web editors, but they can occur if a user writes HTML directly. It is a
well-known fact that a lot of existing web pages are incorrect. All the
major web browser are very tolerant in accepting incorrect HTML documents
and showing them to the user as well as possible.

If a mailer is asked to e-mail an incorrect HTML document, there are two
choices. Either make it correct before sending it, or coping with the
incorrectness. Making it correct before sending it sounds like the natural
way to go, but this can cause problems. For example, if a user wants to
take an existing web page in the Internet or an Intranet and send it by
e-mail, correcting it may make hyperlinks invalid (unless also a lot of
other documents are changed at the same time).

The IETF MHTML standard was carefully designed with the goal that it should
be possible to take existing HTML documents in the Internet or in an
Intranet and send them unchanged via e-mail. Many of the technical problems
are caused by this goal. There are many reasons why this is important. For
example, in the future we will probably more and more often see web
documents with digital seals and signatures on them, such seals and
signatures are broken if you modify the document. Also, modifications may
cause hyperlinks in other documents to become invalid. And everyone knows
how important it is to reduce the risk of invalid hyperlinks.

This is typical of the kind of problem which crop up during implementation
work. It is difficult, when writing a proposal for a standard, to recognize
that kind of problem. The IETF method of developing standards is that
standards go through three stages: proposed, draft and full standard. And
only when there is enough real implementation experience, does IETF allow a
standard to progress from proposed to draft. This method of developing
standard means that there will be less bugs and problems with the standards
than if one first developed the standards, and then started implementing
them.

(b) Relative URLs are very common in the WWW. Instead of specifying an URL
as for example, a URL (hyperlink) is specified as "/images/ietflogo.gif"
instead of as "http://www.ietf.cnri.reston.va.us/images/ietflogo.gif". To
use relative URLs, the web browser must "resolve" them, i.e. translate them
to absolute URLs. This is done using a so-called BASE. For example, if the
relative URL "/images/ietflogo.gif" occurs in a document with the URL
"http://www.ietf.cnri.reston.va.us/document.html" then the base is taken
from this document.

The meeting in Munich discussed certain issues on which BASE to use in
certain special cases of sending HTML via e-mail. These special cases will
probably not occur often in real life.

There were representatives of many of the major implementors during the
meeting, including Microsoft, Netscape, Quallcomm/Eudora and Lotus, and
everyone was very eager to try to achieve a common standard accepted by
all. I am really impressed by the competence of and fairmindedness of
people from different companies at IETF meetings in trying to find commonly
agreed solutions.
> }
> }* What were the main differences in HTML formatting/handling among
> }Microsoft, Netscape, and Eudora e-mail clients prior to the MHTML proposed
> }standard?
> }
I am not aware of any such specific differences between manufacturers. The
current alpha versions of software at various developers do of course have
certain bugs, which may be different between different softwares, but these
differences will disappear when the bugs are corrected.

A general comment on competition and cooperation: The Internet is growing
at a very fast rate. The larger the Internet gets, and the more it is used,
the larger sales for hardware and software manufacturers. Well-working
standards, which allow software to work together, will make the Internet
grow faster and will thus increase the sales. Thus, it is not in the
interest of manufacturers to develop incompatible standards. Manufacturers
will earn more money by cooperating than by deviating. Wise computer
software manufacturers understand this. They understand that they will
earn more money by making the Internet grow faster, than they will earn
by trying to take market shares from each other. I am writing this because
I get the impression from your question that you are hinting at the idea
that manufacturers find it in their interest to outcompete each other by
incompatible features. I do not think such a view is a correct description
of how the Internet market works. Trying to outcompete each other with
incompatible features may be good marketing strategies in a stable market,
where all growth for one manufacturer is taken from the market shares
of other manufacturers. But the Internet is not at all any such stable
market.

An example: Since only a few manufacturers are developing HTML readers
(= web browsers) other manufacturers of e-mail software will often
not develop full web browsers of their own, they will instead access
a web browser from another manufacturer to display html-formatted
messages. And the manufacturers of web browsers seem to be willing
to provide the necessary hooks to allow this.

A comment on sending HTML in e-mail: E-mail today is usually just plain
text, and it is obvious that it will be a large advantage to be able to
send formatted documents with pictures in them in e-mail. There are other
standards than HTML which could be used for this, but HTML will probably
become the breakthrough in a standard for formatted documents with pictures
which are implemented by so many different e-mail software products that it
becomes really useful.

Another advantage with HTML in e-mail is the ability to send forms by
e-mail. One can easily think of thousands of applications for this, I will
just mention one: Scheduling a meeting. You send a form with a list of
proposed meeting dates, each recipient checkboxes those dates which suits
that user, and returns the filled-in form. (An alternative method would be
to have data bases containing everyone's calendars, in which booking could
be done automatically, but that method has many problems, especially if you
want to schedule meetings between people working in different
organisations.)

------------------------------------------------------------------------
Jacob Palme                     Stockholm University
Non-tenured professor           and KTH Technical University
E-mail: [log in to unmask]        WWW: http://www.dsv.su.se/~jpalme
Snail mail: Skeppargatan 73     Personal phone: +46-8-16 16 67
S-115 30 Stockholm, Sweden      Personal fax: +46-8-783 08 29

Back to: Top of Message | Previous Page | Main MHTML Page

Permalink



LISTSRV.NORDU.NET

CataList Email List Search Powered by the LISTSERV Email List Manager