ietf-822
[Top] [All Lists]

Re: The <cid: ...> URL - who implements it?

2001-02-12 10:39:42
At 21.51 +0000 01-02-09, Charles Lindsey wrote:
 >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).

Is it the general opinion that such an extension of RFC 2110
is desirable?

In the case of absolute URLs of the http://foo.bar/file.ext type, it
has already become common practice that such URLs are interpreted as
links in e-mail even if they are not framed as in
<URL:http://foo.bar/file.ext>.

But I guess you are thinking of relative URLs, where the main text
could say:

... for more info, see <URL:attach-one.html> ...

and the next body part would then have

Content-Location: attach-one.html

Your proposal actually raises two issues:

(1) A standard for interpreting URLs in text/plain,
    possible combined with an attribute, for example
    Content-Type: text/plain; URL=interpret

(2) To use RFC 2110 to send a set of linked pages.

Of these items, (2) does not really require any change
to RFC 2110, it just requires that implementors decide
to implement this way of using RFC 2110.
--
Jacob Palme <jpalme(_at_)dsv(_dot_)su(_dot_)se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/