I still think it is better to use HTML than to invent a new
markup language based on text with some URL support. If, however
there is a large wish for such a simplified markup language,
this could of course be done.
Two examples of use of HTML in e-mail, which shows the
benefits of HTML compared to plain text in some cases,
can be found at:
http://dsv.su.se/jpalme/ietf/mhtml-example-1.html and
http://dsv.su.se/jpalme/ietf/mhtml-example-2.html
Simon J points out (see below) that there already is a
format for hyperlinks in plain text, the format like
<URL:http://www.ietf.cnri.reston.va.us/rfc/rfc1738.txt?number=1738>
So if this is to be recommended for URLs in e-mail, and extended
to also support "cid:" URLs, something like
<URL:cid:<G8Dx1o(_dot_)305(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk>
might be explicitly specified in some future standard.
Charles Lindsey proposes this as a method to send a message
with a list of links to information in other body parts.
The functionality for this would be rather similar to ordinary
mail attachments, but with added functionality to put the
link into the right context in the text. This is not unreasonable,
provided that you hate text/html but still want some of its
functionality.
However, my experience from my personal usage of HTML in
e-mail is that there are other very useful uses of HTML
in e-mail. I personally use HTML in e-mail only when I am
replying to a personal message in HTML format, or when
I have special needs for HTML facilities. The special
needs for HTML facilities occurs mainly in two cases:
(a) I want to include one or more in-line pictures in
my message.
(b) I want to quote formatted text from some source
such as a book or web page, and want to show the
formatting in the original source.
So it is not good that the proposal for URLs in ordinary
text does not support neither of these uses. The most important
of them is in-line pictures.
There is another way of putting in-line pictures in MIME.
This is to have a series of body parts:
(1) Text before first picture in text/plain format
(2) The in-line picture as image/gif format
(3) Text after the first picture in text/plain format
This might be a solution, although a problem is that many
mailers handle all body parts except the first as attachments,
even if they have Content-Disposition: Inline on them.
It is somewhat more restricted than HTML in that you
cannot mix picture and text in the same text line.
----
If there is a wish for this to be made a standard, where
should it be specified? In a revised version of the MHTML
standard (RFC 2110) or in a revised version of the
Content-ID standard (RFC 2111) or a new separate RFC
on this topic. If you intend to combine "cid:" with
"Multipart/related" then a revised version of RFC 2110
might be the best place for this.
What are the opinions of implementors of mail and news
clients? Would you implement this if it is made a standard?
Do you want me to produce a revision of RFC 2110 where
this is added?
At 11.24 +0000 01-02-07, Charles Lindsey wrote:
>It seems silly to invent a new rich text format just because you
dislike HTML. Would it not be better, instead, to analyze the reasons
you dislike HTML, and specify a subset of HTML including restrictions
on where to use it, which satisfies your needs but avoids what you
dislike in HTML. If such a subset of HTML could be defined and avoids
your problems with HTML, it would allow reading software to use the
same code for interpreting full HTML and the subset you allow.
So only the producing software need to be rewritten to support
the new format.
But that is no solution. There would be no way to enforce adherence to
such a subset, and you grossly under-estimate the pathological hatred of
HTML when people try to use it on Usenet.
At 14.02 +0100 01-02-02, Simon Josefsson wrote:
<URL:...> could be used inside plain text. From RFC1738:
APPENDIX: Recommendations for URLs in Context
URIs, including URLs, are intended to be transmitted through
protocols which provide a context for their interpretation.
In some cases, it will be necessary to distinguish URLs from other
possible data structures in a syntactic structure. In this case, is
recommended that URLs be preceeded with a prefix consisting of the
characters "URL:". For example, this prefix may be used to
distinguish URLs from other kinds of URIs.
In addition, there are many occasions when URLs are included in other
kinds of text; examples include electronic mail, USENET news
messages, or printed on paper. In such cases, it is convenient to
have a separate syntactic wrapper that delimits the URL and separates
it from the rest of the text, and in particular from punctuation
marks that might be mistaken for part of the URL. For this purpose,
is recommended that angle brackets ("<" and ">"), along with the
prefix "URL:", be used to delimit the boundaries of the URL. This
wrapper does not form part of the URL and should not be used in
contexts in which delimiters are already specified.
In the case where a fragment/anchor identifier is associated with a
URL (following a "#"), the identifier would be placed within the
brackets as well.
In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may
need to be added to break long URLs across lines. The whitespace
should be ignored when extracting the URL.
No whitespace should be introduced after a hyphen ("-") character.
Because some typesetters and printers may (erroneously) introduce a
hyphen at the end of line when breaking a line, the interpreter of a
URL containing a line break immediately after a hyphen should ignore
all unencoded whitespace around the line break, and should be aware
that the hyphen may or may not actually be part of the URL.
Examples:
Yes, Jim, I found it under <URL:ftp://info.cern.ch/pub/www/doc;
type=d> but you can probably pick it up from <URL:ftp://ds.in
ternic.net/rfc>. Note the warning in <URL:http://ds.internic.
net/instructions/overview.html#WARNING>.
--
Jacob Palme <jpalme(_at_)dsv(_dot_)su(_dot_)se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/