Subject: RE: Multipart voice-message, fax-message, etc

From: "Larry Masinter" <[email-masked]>
Date: Mon, 3 May 1999 08:32:52 PDT

> Some time ago, there was some discussion about how to proceed with
> identification of primary message content.  Some have suggested that
> alternatives to those indicated in <draft-ema-vpim-um-01.txt> should be
> considered.

I thought that people were leaning toward just adding a different
content-disposition inside some parts of multipart that indicated
that some parts were optional, and then noting that MDNs for multiparts
shouldn't note that the message was "read" unless all of the parts
were "read".

> I am wondering if these discussions have been progressing at all behind the
> scenes.

Or just in a different scene.

> There is one Internet fax related proposal on the table, and another
> waiting in the wings, for dealing with message-related issues that are
> dependent on the direction taken for the message primary content proposal,
> so I would be very keen to hear how this is progressing.

I dislike the proposal in draft-ema-vpim-um-01.txt, since it defines
the "primary type" by the media type rather than just noting which
parts of a multipart are critical. I also think it's important to note
that often the desire is to confirm processability rather than actual
'read' status.

I also disagree with the characterization:

	Recently, email 
   profiles have been created for both voice [VPIM2] and fax [IFAX] but 
   these are restrictive to only that media and special-purpose computer 
   systems they were intended for. 

since [IFAX] is explicitly not restrictive to 'special-purpose computer
systems', but rather, interoperability with traditional email clients
was a high priority.

Since [IFAX] (simple mode) doesn't mention MDNs explicitly, it would
be better to reference RFC 2532, which does.

Larry

---

From: Graham Klyne <[email-masked]>
Date: Tue, 04 May 1999 17:30:21 +0100

>that often the desire is to confirm processability rather than actual

I understood there to be two purposes to that proposal:

(a) to indicate the primary media type for dispatching purposes (e.g. to
prefer presentation via telephone handset or computer terminal).

(b) to indicate the critical parts of the message.

I also see a third, and less obvious, value in the proposal:

(c) a framework that can indicate the presence of message-related semantics
as opposed to an arbitrary data resource.  The value of this aspect is not
clear, but an example that suggests possible utility is the form of Mike
Ruhl's cover page proposal.

>systems', but rather, interoperability with traditional email clients

I agree with your assertion here, but I note that the possible presence of
special-purpose profiles (e.g. VPIM) tends to underscore the purpose (a)
indicated above.

I think that, before addressing some of the issues you raise, it is
necessary to find some consensus on a broad approach to the purposes
suggested (of consensus that no special approach is needed).

At this point in time, I favour some approach that uses a single
parameterized multipart type to indicate primary media type and
message-related semantics (rather than the multiple types of
<draft-ema-vpim-um-01.txt>) and content disposition labeling to indicate
the critical parts.  I would seek an approach that facilitates the addition
of extra message-related features, such as the cover page proposal.

#g

------------
Graham Klyne
([email-masked])