In <p0501041fb6a87853966b(_at_)[130(_dot_)237(_dot_)150(_dot_)141]> Jacob Palme
<jpalme(_at_)dsv(_dot_)su(_dot_)se> writes:
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.
Yes, that would presumably be the format to adopt. However, I have come
round to the opinion that RFC2110 mechanisms (using Content-Location)
would be more suitable for this particular application that CID
mechanisms, simply because of the requirement that Content-IDs have to be
globally unique, which is unnecessary (and even a nuisance) for this
particular purpose.
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.
I think those are two cases where sending the mail in HTML format would be
appropriate, since you would presumably already be aware that your
correspondent had some capability to display pictures and texts formatted
in that particular way. But it would not be appropriate for normal day-to
day email.
However, it would not be appropriate in News (though technically workable,
of course) because the rules or customs which govern particular newsgroups
or hierarchies tend to prohibit binaries (e.g. pictures) or fancy
formatting. And of course on News you cannot make any assumptions at all
as to what your readers are able to display (except that people who
subscribe to alt.binaries.pictures can presumably display them somehow).
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.
Turnpike is the only mail/news reader I know of that handles multiparts
truly inline (you can even change Content-ID several times within the same
line if you are careful). They claim, of course, that theirs is the only
true implementation of Mime, but the rest of the world seems unconvinced
:-( .
It is somewhat more restricted than HTML in that you
cannot mix picture and text in the same text line.
Turnpike can.
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.
I think an extension to RFC 2110 would be the proper course, if it were
agreed than an RFC was necessary. But whatever is done, if it allows these
particular URLs to be recognised within text/plain (or text/something).
then it should allow for ANY URL to be recognised in text/plain (since
many systems currently attempt to do it ad hoc, and usually
sort-of-successfully).
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Web:
http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 436 6131 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5