ietf-822
[Top] [All Lists]

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

1995-11-27 17:33:18
To follow up on what Roy T. Fielding said ...
  
  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).
  
Consider the following demurrur: The form "message-id?content-id"
is a "well posed" search URI where pre-conditioning over the
message-id means that searching may be limited to parts
(including the root part) found in the cited message.  [By "well
posed" I mean under a suitable mapping of your
relative-url-compatible "general URI syntax" to MIME contexts.]

Nicely put. I note also that forms like "message-id?message-id" (refers to a
nested message within a message) and "message-id?message-id?content-id?"
(refers to a part within a message nested inside of another message) in are
also possibilities. Even "content-id?content-id" is possible, although I don't
think it makes much sense to provide support for it.

The issue is whether or not there is any advantage to allowing for the
specification of additional context in a reference to a message-id or
content-id, and if there is, whether or not we want to tackle this aspect of
the problem right now. One argument for such specification is that it may
improve performance substantially in many cases. (I suspect that while extant
message stores may provide indexing based on message-id, they probably don't
implement indexing based on content-id.) The argument against such
specification is that the things are supposed to refer to identical content, so
why bother with all the extra stuff. However, there are numerous other cases
where different URLs refer to the same content, and we don't seem to mind about
those...

Anyway, I agree with Keith to the extent that I believe the one problem we have
to solve ASAP is that of cross-references between parts in multipart/related.
But I also believe that we'll need to solve the more general problem sooner or
later, and that later is acceptable if we cannot come to terms with the full
problem right now. However, should we elect not to tackle the full problem, we
need to make sure that anything we do now won't preclude solving the general
problem later.

                                Ned