ietf-822
[Top] [All Lists]

Re: Content-Disposition Header

1993-06-26 15:37:56
Excerpts from mail: 26-Jun-93 Re: Content-Disposition Hea.. Keith
Moore(_at_)cs(_dot_)utk(_dot_)edu (1242)

This works as long as "hidden" body parts are required to preceed
the parts that reference them.

Which we could require, if we're willing to state that there's never any
circularities.  Can an object have both "owner" & "requires"?  Can these
things nest or be mutually referential?  How hard it will be to
implement depends on this.  A general-purpose implementation has to be
fairly complex, but if we're willing to say that there's no cycles
(possibly because you can't have both owner  & requires, or possibly
just because you aren't allowed to have cycles, so cycles can be treated
as errors) then a linear implementation is more plausible, but the
general mechanism is less powerful.

One problem with multipart/related is that there is no way to 
have multiple "container" parts (say RTF and HTML) that each
reference several "hidden" parts.  I would like to be able to
have multiple "container" parts under a multipart/alternative,
be able to reference "hidden" parts.  This is because I don't
expect to see a standard "container" emerge anytime soon.

Right.  There's a fundamental tradeoff between simplicity and power;
this is another example of it.  At the moment, I kind of like the idea
of saying that owner & requires are mutually exclusive (i.e. an object
is either a container or contained, but not both), and that the order of
hidden objects and their owners should be specified, with the owner
coming last.   But we should recognize the limitations we're creating if
we do this....