chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk (Charles Lindsey) writes:
So my question is: What systems, if any, currently support it, and exactly
how is it intended to be used?
A mailreader I use (Gnus) have some support for it, and once in a
while I do receive mail containing cid: links.
I don't recall any other use than having one main text/html part with
links to embedded pictures that are stored in other MIME parts of the
message.
Contruct a multipart document (either multipart/mixed or
multipart/digest). The first (introductory) part of it contains
introductory material, including a Table Of Contents referring to the
remaining parts (which themselves might be message/rfc822, or text/plain,
or whatever else, each with its own Content-ID header).
The Table of Contents would include <cid: ... > URLs pointing to the
individual parts. So is there any software out there that would support
such a usage (e.g. by enabling you to click on the TOC entry so as to
cause the corresponding part to be displayed)? And what Content-Type
should the introductory part be? Text/plain, or something special?
text/plain with <URL:...> urls, or perhaps more reliable text/html
with <img src=...> or <a href=...> would work.
I'm not aware if any of the big clients would do something sensible
given such messages though.
A possible application for this kind of thing would be FAQs published in
newsgroups, but there are likely others.
Sending complete web pages (including images) via mail is the only use
I've seen yet.
A related question is the general usage of URLs in text/plain material.
Many reading agents try to detect these (usually pretty accurately, but
with occasional mistakes) and to highlight them. Is this usage formally
documented anywhere and, if not, should it be (perhape with supporting
parameters in the Content-Type header)?
<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>.