[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Revised proposal
On Tue, Sep 17, 2002 at 10:52:04AM -0600, Doug Royer wrote:
>
> > 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 ...
How about:
If the payload of a BEEP packet contains exactly one text/calendar
body part, it MUST ...
Is this what you mean?
>
> 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?
Right but in 1.1 I'm talking about text/calendar only, as in an endpoint
which doesn't support any multipart.
> > 1.2 multipart/related
>
> How about '1.2 multipart' as there are several multipart types.
Yes
> > 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.
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.
> >
> > 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?
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.
> > 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
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.
> 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.
Do you mean (2) can be used with one text/calendar object per ANS in
a ANS/NUL reply? If so, I agree.
> 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.
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.
> 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.
I agree it's out of scopr to specify how, but it's in scope to state
this must be done.
>
> >>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.
>
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:a.campi@xxxxxxx
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