Subject: Re: Proposal about multipart etc

From: [email-masked]
Date: Thu, 12 Sep 2002 11:48:54 -0400

Andrea, I like your proposal a lot.  it's clear and concise.  Anyone else 
on the list - please respond to Andrea with yoru comments.  We always like 
it when someone goes to this length to provide actual text ( 8-) ) that we 
can incorporate in a draft document.  I know you are out there - there are 
over 300 people subscribed to this list - let's hear from you! Thanks.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

Andrea Campi <[email-masked]>
Sent by: [email-masked]
09/11/2002 07:32

        To:     [email-masked]
        cc: 
        Subject:        Proposal about multipart etc

Hi all,

I'm writing this as a proposal to help focus the discussion and above
all make sure I make my point clear. I think at least a few people
agree on my point of view, so I hope nobody finds this out of place.
I'm not asking to include this text in the draft unless people agree
on all of it. And please excuse my english but I'm not a native
speaker.

 1 Multipart in CAP              [note: addition/revision to 3.3.1 in 
current draft]

The BEEP data exchanged in CAP may take different forms depending on
the data being exchanged and the capabilities of the CUA and the CS.

If data can be sent in different forms, it is advisable to send it
as text/calendar. In particular, most commands can be sent as
test/calendar.

 1.1 text/calendar

If the payload of a BEEP packet is of type text/calendar, it MUST
conform to [iCAL] iCalendar format. This is the only format which
all CAP implementations MUST accept.

 1.2 multipart/related

If the exchanged packets contain multipart/related payload, they MUST
contain at least one text/calendar parts. If it contains more than
one, they are processed in the same order as they appear [note: I
have no strong opinion on this point]. Data in text/calendar parts
MUST conform to [iCAL] iCalendar format.
If a CUA or a CS don't support this form, they MUST respond with an
appropriate REQUEST-STATUS.

[note: obviously, text/calendar MAY be inside text/alternative, and
parts with unknown MIME types can be thrown away. I don't think we
need to state this here]

If needed, additional data can be transmitted in addidional body
parts using the appropriate MIME type; in particular, this can be
used for attachments. Additional body parts are referred to using
CID: etc.

 2 Multipart negotiation

A CUA and a CS SHOULD negotiate the level of multipart support.
This can be done using the GET-CAPABILITY command [note: we must
add a property for this].
A party should assume the other party can't do multipart, and send
a GET-CAPABILITY command as text/calendar. If the answer states that
the other party supports multipart, it can send subsequent commands
using the appropriate form.
As an alternative, a party may opt to start using multipart and switch
to the simpler text/calendar form if it receives an error.

 3 Considerations

 3.1 Graceful degradation

If both parties support multipart, each party may opt to use the
encoding it prefers. However, text/calendar support is mandatory,
which in particular means a CS MUST use text/calendar in replies
to commands if the party only supports that form, with no loss of
data except as indicated in 3.2.
In particular, if the CUA only supports text/calendar:

 - all replies to commands with multiple targets or multiple queries, as
well as replies containing separate components with different METHODs,
must be sent with different iCalendar objects in the same text/calendar

[note: add more here if we want to. I know this is already present
in iCal]

 3.2 Limitations

 3.2.1 cid: URI

A CUA or a CS which doesn't support multipart can't properly handle
properties with a cid: URI value; this affects ATTACH properties and
any property which allows the ALTREP parameter.

A limited CUA SHOULD inform the user that there is an attachment but
it is not able to access it. It should also provide alternative ways
to attach files to outgoing components. One method would be to store
the file on an appropriate file store and store the URI.

A limited CS SHOULD try not to lose ATTACHments. One method would be
to provide an iMIP+CAP client that stores attachments on any appropriate
file store (examples include IMAP, HTTP, FTP, WebDAV) and rewrite
ATTACH properties to reference the appropriate URI. It is advisable
that CS which have no limitations, but want to support clients with
limited capabilities, do the same conversion, either at time or
retrieval time.

A final note: I purposefully don't address the problem of a limited
CUA or CS not being able to properly process an iMIP message. As some
people noted on the list, a CUA does not HAVE to know about iMIP, nor
does a CS; in fact, a CUA doesn't have to deal with email at all.

If the implementator wants iMIP support it can still use the same
approach as in 3.2.1, that is provide an iMIP+CAP client to do the
processing. This would probably take the form of a filter inside a
MTA or MUA application.

I think this proposal addresses all concerns presented on the list
by advocates of both approaches. An implementor is free to choose
to support limited or complete functionality without limiting the
user. At the same time, this doesn't in any way (that I know of)
violate or restrict any existent RFC.

I expect that complete applications like Outlook or Ximian Evolution
would support the whole enchilada (they have to, anyway), while light
clients (cell phones, CGI interfaces etc) can be much simpler.

Bye,
                 Andrea

-- 
Andrea Campi                              mailto:[email-masked]
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D                                            phone: 
+39 02 32863 ext 1
v. Darwin, 85 - I-20019                                            fax: 
+39 02 32863 ext 7705
Settimo Milanese (MI), Italy