LISTSERV mailing list manager LISTSERV 15.5

Help for MHTML Archives


MHTML Archives

MHTML Archives


View:

Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font

Options:

Join or Leave MHTML
Reply | Post New Message
Search Archives


Subject: multipart/related with no parent part?
From: Laurence Lundblade <[log in to unmask]>
Reply-To:IETF working group on HTML in e-mail <[log in to unmask]>
Date:Mon, 1 Jul 1996 08:55:20 -0700
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (42 lines)


I would like to propose rearranging the parameter named "type" in
multipart/related so that multipart/related can be used for compound
documents that have no "parent" part. The value in this is in a generic
form for aggregation. A client app can then offer run an external viewer on
the collection even if it doesn't recognize the particular compound
document type. That is the app would have different defaulting behavior for
multipart/related than for multipart/mixed.

The VPIM (voice profile for Internet mail) is an example of where this
might be useful. In one form this is a multipart/voice-mail part
encapsulating an audio/32kadpcm part and an application/directory part.
There is no reference between the two parts such as an HTML tag, but they
very much need to be kept together tightly since the second part provides
information about the sender of the first.  The advantage of using
something like multipart/related; type=voice-mail comes when mailers can
support this multipart/related binding for types they don't know about. If
we use multipart/voice-mail then a mailer knowing nothing about that type
will default it to multipart/mixed and the binding will be lost.

I would suggest we have two type parameters: parent-type and
aggregate-type. The parent-type would replace the type we have now and
label the type of the parent part pointed to by the start parameter. The
values for parent-type parameter are clearly the value we are using now for
the type parameter.

The aggregate-type parameter would be used in place of creating more
specialized multipart types like multipart/voice-mail. The values for
aggregate-type seem less clear, but perhaps we can say they are always
consist of a MIME type/subtype even though these type/subtypes wouldn't
ever exist as a MIME structure (e.g. multipart/related;
aggregate-type="application/voice-mail". Alternatively we could consider
the parameter values a sub-sub-types of multipart/related and register them
in some appropriate way. (e.g., multipart/related;
aggregate-type=voice-mail).


Laurence Lundblade, Qualcomm Inc   <[log in to unmask]> 619-658-3584
---
 Maybe in order to understand mankind, we have to look at the word
 itself: "Mankind".  Basically it's made up of two separate
 words - "mank" and "ind". What do these words mean?  It's a
 mystery, and that's why so is mankind.  - Jack Handy

Back to: Top of Message | Previous Page | Main MHTML Page

Permalink



LISTSRV.NORDU.NET

CataList Email List Search Powered by the LISTSERV Email List Manager