LISTSERV mailing list manager LISTSERV 15.5

Help for MHTML Archives

MHTML Archives

MHTML Archives


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


Join or Leave MHTML
Reply | Post New Message
Search Archives

Subject: Re: Web Week: MHTML questions
From: Einar Stefferud <[log in to unmask]>
Reply-To:[log in to unmask]
Date:Sun, 24 Aug 1997 00:26:55 -0700

text/plain (137 lines)

Please note that all this must be used in the press without
attribution of the source.  I do not want to become the focus of IETF
actions to prevent violations of long standing policy against WG
Chairs or Editors issuing press releases, or granting on the record

From Jacob Palme's message Sat, 23 Aug 1997 19:25:25 +0200:
}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
}(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 "". 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
}"" 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
}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
}Jacob Palme                     Stockholm University
}Non-tenured professor           and KTH Technical University
}E-mail: [log in to unmask]        WWW:
}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



CataList Email List Search Powered by the LISTSERV Email List Manager