ietf-822
[Top] [All Lists]

Re: The TEXT/HTML Content Type in e-mail

1995-11-27 14:59:11
This discussion is getting really confusing.  I agree with Larry in
that Content-IDs should be an absolute form, since they never express
a relative construct.  It is not possible to use message ids in relative
forms because the message-id URL does not require "/" to represent
hierarchy (nor should it).

What is confusing is all the hoops that we are jumping through just
to map the embedded URLs to their e-mail equivalent.

There are 3 cases:

1) The embedded URL is relative to the path of the first part's location
2) The embedded URL is relative to some abstract BASE URL other than (1)
3) The embedded URL is absolute
4) The embedded URL is cid:....

Although 3 and 4 are really the same, I differentiate them just to point
out that there is nothing wrong with explicitly using the (proposed) cid
URL within the HTML part.

Case 3 is important -- just because a URL is in absolute form does not
mean that the UA should be required to retrieve it from that location.
If the entity corresponding to that location is included as another part
of the multipart message, then the UA must be able to recognize it as
such and use the local part.  This requires either a catalog part (mapping
content-ids to locations, etc.) or a Content-Location on each part.
I prefer the latter.

Case 2 is necessary for those times when the location of the referrer
has nothing to do with the embedded relative URLs within the referrer.
This is the case for a table of contents which is distributed
independently of the main content.  This case requires a Base
(or Content-Base) header field for each part that makes this distinction.

Case 1 is the obvious case, but it is the only one for which
Content-Disposition has any relevance.  However, disposition cannot
ensure a duplication in paths, so references like "../icons/smiley.gif"
won't work anyway.  BUT, since the UA *can* determine the correct part
by parsing the embedded URL relative to the referrer's Content-Location
and then comparing the resolved URL to the Content-Location of the
other message parts, using Content-Disposition for this purpose isn't
even necessary.

So, I suggest that

      Content-Location: absoluteURI
and   Content-Base: absoluteURI

be defined, stating explicitly that LWSP-chars inside the field value
be ignored so that the URL can be folded over several lines.
[Note: surrounding the URL with double-quotes is not necessary if it
 is the only content of the field].

In fact, I can do this as a revision to RFC 1808, since this really
does impact that specification.


 ...Roy T. Fielding
    Department of Information & Computer Science    
(fielding(_at_)ics(_dot_)uci(_dot_)edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/