Subject: Re: Revised proposal

From: Doug Royer <[email-masked]>
Date: Tue, 17 Sep 2002 10:52:04 -0600

>  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.

How about:

   If the payload of a BEEP packet contains a text/calendar body part,
   it MUST ...

because:

A multipart message is of type 'multipart' (not text/calendar), and it
can contain one or more text/calendar body parts, each of which may
have references to other body parts in the same MIME object - correct?

 >  1.2 multipart/related

How about '1.2 multipart' as there are several multipart types.

 >>[note: this amendment was proposed by George Babics; there was one
 >> objection but didn't provide evidence to support the need for more
 >> than one text/calendar part. If anybody care about this I can change
 >> it back to the original text.]
 >>If the exchanged packets contain multipart/related payload, they MUST
 >>contain exactly one text/calendar parts, which must conform to [iCAL]
 >>iCalendar format. If a CUA or a CS doesn't support this form, they MUST
 >>respond with an appropriate REQUEST-STATUS (TBD).
 >
 >
 > 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.

How about:

   A CS MUST send the MULTIPART capability and a CUA MUST send
   the MULTIPART capability when the CUA supports sending CAPABILITY.

   If the CUA does not support CAPABILITY, the CS MUST assume that
   the CUA does not support any multipart.

   The value of the MULTIPART capability may be empty meaning that
   no multipart is supported by that endpoint.

 >
 >  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.

Do you mean 'inline' vs 'body part' as 'encoding' is BASE64, binary, ...?

Or do you mean multipart vs single body part?

 > 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

You can't mix METHODs in the same MIME object (That's a restriction
from one of the 244[567] RFC's). So each endpoint that does not
support multipart MUST be able to receive the following as one
command reply:

     (1) One MIME object of type text/calendar. (Not multipart)
         And each text/calendar must contain one or more iCalendar objects.
         All with the same METHOD.

     (2) Multiple MIME objects each of type text/calendar (Not multipart)
         And each text/calendar must contain one or more iCalendar objects
         of the same METHOD.

And each endpoint that is able to receive multipart must in addition
to (1) and (2) above be able to receive:

     (3) A single multipart MIME object of the types it specified in its
         CAPABILITY reply. Where each MIME object must contain at least
         one text/calendar and may contain other body parts. And each
         text/calendar object must contain one or more iCalendar objects.
         All iCalendar objects in all of the text/calendar body parts,
         must be of the same METHOD.

     (4) Multiple multipart MIME objects of the types it specified in its
         CAPABILITY reply. Where each MIME object must contain at least
         one text/calendar and may contain other body parts. And each
         text/calendar object must contain one or more iCalendar objects.
         All iCalendar objects in all of the text/calendar body parts
         with a single MIME object, must be of the same METHOD.

 >  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 CUA or CS can always inline attachments or make them body parts
when supported. This has no effect on a CUA or CS ability to
support ATTACH. The size limit is a separate issue.

If a CUA or CS does not support multipart, then all ALTREP
values must be stored external to the text/calendar object
and can not be transmitted using CAP.

I think it is out of scope for CAP to specify how.

 >>A limited CUA SHOULD inform the user that there is an attachment or
 >>ALTREP 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; or it could
 > opt to inline the referenced data.

I would say:

  WHEN the other endpoint does not support multipart then:

   (1) ATTACH values MUST BE inlined. If it can not fit because
       of size limits, then a size error must be given.

   (2) ALTREP values that are in other body parts to the same MIME object
       can not be transmitted using CAP. A CUS or CS implementation may
       provide storage for the ALTREP value and modify the ALTREP value
       in the iCalendar object to point to the external value. How this is
       handled is not specified in CAP. Or they may issue an error.

---

From: Andrea Campi <[email-masked]>
Date: Tue, 17 Sep 2002 20:25:35 +0200

How about:

    If the payload of a BEEP packet contains exactly one text/calendar
    body part, it MUST ...

Is this what you mean?

> have references to other body parts in the same MIME object - correct?

Right but in 1.1 I'm talking about text/calendar only, as in an endpoint
which doesn't support any multipart.

> How about '1.2 multipart' as there are several multipart types.

Yes

>   no multipart is supported by that endpoint.

I like your text but it should be in addition to what I proposed -
you mention HOW the negotiation works, but not that it SHOULD (or
MUST, if you prefer) happen. So in addition to your text:

    Both endpoints SHOULD (or MUST) send the GET-CAPABILITY command
    before using multipart objects.

> Or do you mean multipart vs single body part?

I agree this sentence could be written better, but I'm not sure I
understand your question. How about:

    If a CUA doesn't support multipart, the CS MUST still send all
    meaningful data. To this end, it might rewrite data as it sees
    fit, as detailed in 3.2.

Then again, it doesn't seem to be terribly useful so I might as well
remove it.

> from one of the 244[567] RFC's). So each endpoint that does not

Well, it's in RFC2447, and in the recent thread we didn't reach a
consensus whether we are exchanging true iMIP messages (and therefore
bound to RFC2447) or iTIP messages. I'd say CAP is a different binding,
at the same level as iMIP.

Obviously we need to agree on this before going on.

>         And each text/calendar must contain one or more iCalendar objects

Do you mean (2) can be used with one text/calendar object per ANS in
a ANS/NUL reply? If so, I agree.

> support ATTACH. The size limit is a separate issue.

I agree.  Note that I wrote "can't properly handle properties with a
cid: URI value". I mean exactly that: if no multipart is usable in this
session, an endpoint must examine the value and if they contain a cid:
URI take corrective measures, which might be inlining or storing
externally.

> I think it is out of scope for CAP to specify how.

I agree it's out of scopr to specify how, but it's in scope to state
this must be done.

>       handled is not specified in CAP. Or they may issue an error.

I don't see why external storage is not applicable to (1), too. I
think providing an alternative here is acceptable. Besides, if we
don't specify this, a compliant CS can still use external storage
and the CUA wouldn't even notice, so we can't forbid extenal storage
even if we wanted to...

Bye,
	Andrea

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

---

From: Doug Royer <[email-masked]>
Date: Tue, 17 Sep 2002 14:59:50 -0600

>     If the payload of a BEEP packet contains exactly one text/calendar

With your note (below - that it means - multipart) - yes.

> which doesn't support any multipart.

  ---

>     before using multipart objects.

Re-read it 'MUST' is used 3 times. Each end MUST tell the
other if it supports MULTIPART. Otherwise things will not work.

> a ANS/NUL reply? If so, I agree.

Currently I have left BEEP out of it, I mean the the CS or CUA
can send one or more text/calendar MIME objects, each with a unique
METHOD. And each can contain multiple iCalendar objects.

> I agree it's out of scopr to specify how, but it's in scope to state

I disagree - the endpoint MUST do it OR send an error.
My CELL phone will not be exporting files - as an example,
even if it can do body part ATTACH and body part ALTREP.

> and the CUA wouldn't even notice, so we can't forbid extenal storage

I agree.

---

From: "Shannon J. Clark" <[email-masked]>
Date: Tue, 17 Sep 2002 16:38:17 -0500

Doug,

Quick note re one comment below:

Already multiple cell phone vendors (and networks) support cell phones with
camera attachments - which allow for the emailing of image files.

The next step of connecting that camera to other applications in the cell
phone (like calendars) seems very logical and easy to image (and useful).

For example - a meeting coordinator might email photos of a location to all
the attendees, or each attendee might attach a photo of themselves to aid
identification, or the item to be discussed at the meeting might be sent to
all attendees as an attachment.

As the lines between cell phones, PDAs, pocket computers, and laptops grow
increasingly meaningless I think we are wise to assume that current "small"
devices may already need to do tasks we mostly envisioned only "fat" clients
doing (like attaching files).

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Doug Royer
Sent: Tuesday, September 17, 2002 4:00 PM
To: [email-masked]
Subject: Re: Revised proposal

---

From: Doug Royer <[email-masked]>
Date: Tue, 17 Sep 2002 16:20:10 -0600

> doing (like attaching files).

I think we agree, I am just saying that 'attachments' ARE possible.
However the cell phone is unlikely to be an HTTP or FTP server so that
external attachments can be downloaded from the cell phone. So I was saying
that if the other (non-cellphone) does not support multipart, then the cell
phone can not send attachments at all as it is not going to replace the body 
part with an ftp:<mycellphone#>/attachemnt-3 URI and tell the world it is an
FTP server. So a cell phone (or whatever), may elect to send and error if it
can not send attachments.

---

From: Andrea Campi <[email-masked]>
Date: Wed, 18 Sep 2002 10:06:14 +0200

> METHOD. And each can contain multiple iCalendar objects.

I don't see how BEEP can be left out without confusing the matter...
Anyawy, this is ok with me as long as it means one text/calendar per
[whatever underlying transport protocol] "message". This is not ok
if it means more than one text/calendar per message, as it means
we would need to tell where one text/calendar object ends and a new
one begins, i.e. basically reinvent MIME.

> even if it can do body part ATTACH and body part ALTREP.

You've taken my answer out of context. I answered to a comment
you made on my original statement of a FACT - if an endpoint has
limited capability, it MUST do something about it, including
responding with any relevant error. So it seems we agree.

In your example (a mobile phone which can do multipart but connects
to a server that can't) it would still be possible to inline the
data or store it to an external server. If it can reach the CS,
I see no reason why it would not be able to reach an IMAP server,
and IMAP protocol would probably be supported on that phone anyway.

Bye,
	Andrea

---

From: Andrea Campi <[email-masked]>
Date: Wed, 18 Sep 2002 10:12:43 +0200

> doing (like attaching files).

I don't know how things work in the US, but here in Europe odds are
all parts are (at least partly) under control of a service provider.
If the service provider is going to use a limited CS, it's very
reasonable to expect it would also have an external store (be it
FTP, HTTP, WebDAV, IMAP, etc) _AND_ the cell phone would know how
to use it to its advantage. This is useful not only to a CUA -
think automatic slideshow of the pictures you take, etc...

So I guess I agree with you, but I think "small" devices will still
need external assistance to work optimally.

Bye,
	Andrea

---

From: George Babics <[email-masked]>
Date: Wed, 18 Sep 2002 09:30:30 -0400

Doug Royer wrote:

...

>    no multipart is supported by that endpoint.

How about making sending CAPABILITY a MUST for both the CS and CUA?
It can make things simpler, and it should not add too much complexity
to and burden on the CUA.

George

---

From: Doug Royer <[email-masked]>
Date: Wed, 18 Sep 2002 11:24:03 -0600

> to and burden on the CUA.

I have no problem with that, I thought others objected.

If there are no objections, I'll change '9.3' to be:

9.3 GET-CAPABILITY Command

    CMD: GET-CAPABILITY

    Purpose: The GET-CAPABILITY command returns the capabilities of the
    other end of the session.

    A CUA MUST send a GET-CAPABILITY command to a CS. The CUA MUST NOT
    send any other commands until it has the GET-CAPABILITY reply from
    the CS.

    The CS MUST send a GET-CAPABILITY command to any CUA. The CS MUST NOT
    send any other commands until it has the GET-CAPABILITY reply from
    the CUA.

WAS:

9.3 GET-CAPABILITY Command

    CMD: GET-CAPABILITY

    Purpose: The GET-CAPABILITY command returns the capabilities of the
    other end of the session.

    A CUA MAY send a GET-CAPABILITY command to a CS.  The GET-CAPABILITY
    command MUST BE implemented by all CSs.

    The CS MAY send a GET-CAPABILITY command to any CUA.  The GET-
    CAPABILITY command MAY be implemented by a CUA.

---

From: Andrea Campi <[email-masked]>
Date: Wed, 18 Sep 2002 20:13:59 +0200

I agree.

I would add:

	The GET-CAPABILITY command MAY be implemented by a CUA.
	If it's not, a CS MUST assume all capabilities take the default
	values.

---

From: Doug Royer <[email-masked]>
Date: Wed, 18 Sep 2002 14:56:51 -0600

Andrea,

If you read George's post, you will see that he thought it should
be a MUST (not a MAY), so my proposal (that you responded to) agreed
with him.

Do you object to George's proposal that a CUA MUST ask GET-CAPABILITY?
Or are you saying you can go with a MUST or a MAY and that
is is not that important to you?

---

From: Andrea Campi <[email-masked]>
Date: Wed, 18 Sep 2002 23:59:33 +0200

> is is not that important to you?

I agree with both of you that a CUA MUST send the GET-CAPABILITY.
I agree with both of you that a CS MUST send the GET-CAPABILITY.
Everybody agrees a CS MUST implement and respond to the GET-CAPABILITY.

I was merely suggesting (but I would not fight over this if somebody
opposed it) that we could keep GET-CAPABILITY implementation and
response optional, as in the existent text. So a CS would still send
it and get back a REQUEST-STATUS:9.0;Unimplemented. In this case the
CS should simply assume the CUA uses the defaults for all properties -
we just have to make sure the defaults are reasonable, of course.

This would slightly simplify really naive implementations of CUAs
(say, a simple CGI which offers a read only view of a public agenda),
by allowing them to implement no command at all.

Bye,
	andrea

---

From: Doug Royer <[email-masked]>
Date: Thu, 19 Sep 2002 09:56:21 -0600

I believe that you are stating that CAP should not change.
What you are suggesting now is what the draft currently states.

Does anyone else agree with George that both the CS and CUA
MUST support GET-CAPABILITY? (I could go with MAY or MUST).

-Doug

---

From: Andrea Campi <[email-masked]>
Date: Thu, 19 Sep 2002 20:48:59 +0200

> MUST support GET-CAPABILITY? (I could go with MAY or MUST).

Sorry there's a misunderstanding somewhere.
I read George proposal (and I strongly agree on that) as changing CAP 
to say both the CS and CUA MUST send GET-CAPABILITY as the first 
command in a session.
I thought this was what you are agreeing to?

I simply added: we may want to leave: the CS MUST support 
GET-CAPABILITY, the CUA MAY.

Is this clearer?

> <smime.p7s>

---

From: George Babics <[email-masked]>
Date: Fri, 20 Sep 2002 09:54:48 -0400

What I proposed was that both the CS and CUA MUST support
GET-CAPABILITY because it may make the draft simpler to
write. It may also make the protocol simpler by having,
at the start, each side clearly state what they support.
(But who should issue the command first, or does it matter?)

However, I do not have strong feelings about this, thus
I am fine with specifying that the CUA MAY or SHOULD support
GET-CAPABILITY.

George

---

From: Gary Frederick <[email-masked]>
Date: Fri, 20 Sep 2002 16:06:49 -0500

Sounds like everyone commenting is ok with MUST. MUST should make the standard a bit simpler. I have not seen a real benefit posted for MAY for the CUA.

Can we have an example conversation that shows a CUA connecting with a CS?
Would the conversation between a CS and a CS be the same?

I would like to see what the GET-CAPABILITY returns.

Gary