[Top] [All Lists]

Re: How we are planning to embed HTML in messages

1995-05-17 07:34:44

"Chris" == Chris Newman <chrisn+(_at_)CMU(_dot_)EDU> writes:

  Chris> The "inline" content disposition has more semantics than what
  Chris> is implicit to the CID URL.

  Chris> How about a content disposition of "embedded", since the part
  Chris> (when properly displayed) is embedded within the view of a
  Chris> different part.

This was the original purpose of the 'hidden' disposition type, which
was dropped from the current C-D spec. Embedded is a better name; I
like it. Perhaps we should IANA-register it one C-D goes RFC.

  Chris> Of course, this leads to the question of what to do with an
  Chris> embedded part if one hasn't yet seen the part it is embedded
  Chris> within.

Exactly the problem that made us take out the 'hidden' disposition
type. I had a parameter that identified the enclosing/organizing
content-id as a way of dealing with this, but that created an
unfortunate many-to-one relationship between subsidiary and primary
bodyparts; you may want to have multiple primary bodyparts (text
vs. graphical version, for example) organizing the same subsidiaries.

  Chris> Perhaps a simpler and better approach would be to have a new
  Chris> multipart type, say "multipart/embedded", where the first
  Chris> part is a hypermedia format (e.g. text/html) with references
  Chris> to the other parts.  The display hint is that if the first
  Chris> part can be fully interpreted, the other parts should be
  Chris> skipped.  It could also be a hint that the other parts are
  Chris> not particularly useful by themselves (e.g. lots of little

This is not a bad approach; you should still label the subsidiary
parts with attachment or embedded dispositions for compatibility with
past and future clients that do not support your scheme, though;
otherwise, they'll default to treating it as multipart/mixed and
display a confusing array of, as you say, red dots!


<Prev in Thread] Current Thread [Next in Thread>