[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Revised proposal

To: ietf-calendar@xxxxxxx
Subject: Revised proposal
From: Andrea Campi <a.campi@xxxxxxx>
Date: Tue, 17 Sep 2002 12:56:33 +0200
List-archive: <http://www.imc.org/ietf-calendar/mail-archive/>
List-id: <ietf-calendar.imc.org>
List-unsubscribe: <mailto:ietf-calendar-request@imc.org?body=unsubscribe>
Organization: I.NET S.p.A.
Sender: owner-ietf-calendar@xxxxxxxxxxxx
User-agent: Mutt/1.5.1i

Hi all,

I updated the proposal with all (I think) the feedback that was
posted on this list; modified lines are marked with a "> " at
the beginning of the line. I hope MUAs don't mess us too much,
so I'm also attaching the file.
There are a few points I need feedback on, I marked those with
notes.

I also added examples, I hope they are useful.




 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.

> [note: I propose this change from my original text.]
> If data can be sent in different forms, it is advisable to send it
> as text/calendar. In particular, most commands SHOULD 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

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

>  This is done by sending the GET-CAPABILITY command and checking
>  for the values of the MULTIPART property. The negotiation can be
>  started by either of the endpoints.

An endpoint should assume the other endpoint 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.

>  In the example below, the CS supports multipart/related in addition
>  to text/calendar. However, the CUA sent no MULTIPART property, which
>  indicates it doesn't support any, so any subsequent data exchange
>  must only use test/calendar.

C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:The CUA's PRODID
C: CMD;ID=12345:GET-CAPABILITY
C: END:VCALENDAR

S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:The CS's PRODID
S: CMD;ID=12345:REPLY
S: BEGIN:VREPLY
S: ...
S: MULTIPART:related, alternative, mixed
S: ...
S: END:VREPLY
S: END:VCALENDAR

S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:The CS's PRODID
S: CMD;ID=12346:GET-CAPABILITY
S: END:VCALENDAR

C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:The CUA's PRODID
C: CMD;ID=12345:REPLY
C: BEGIN:VREPLY
C: ...
C: ...
C: END:VREPLY
C: END:VCALENDAR


> [note: I initially put this in to solicit discussion. If nobody
>  cares I will remove this sentence.]
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.

> [note: this sentence generated discussion on the list, but in fact
>  it's the same issue as for any URI a CUA is unable to access, so
>  it's really just a matter of user interface - and should be removed
>  from here.]
> 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.

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. Another possibility
> would be to inline the referenced data.

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.

> In the first example, multipart was negotiated earlier, so the CS
> knows it can send multipart:

   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.0
   C: PRODID:-//someone's prodid
   C: CMD:SEARCH
   C: TARGET:relcal2
   C: BEGIN:VQUERY
   C: QUERY:SELECT * FROM VEVENT WHERE ....
   C: END:VQUERY
   C: END:VCALENDAR

   S: Content-Type: multipart/related; boundary="boundary-example-1";type=text/calendar
   S: 
   S: --boundary-example-1
   S: 
   S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
   S: Content-Transfer-Encoding: 7bit
   S: Content-Disposition: attachment; filename="event.vcs"
   S: 
   S: BEGIN:VCALENDAR
   S: PRODID:-//ACME/DesktopCalendar//EN
   S: METHOD:REQUEST
   S: VERSION:2.0
   S: BEGIN:VEVENT
   S: ORGANIZER:mailto:foo1@xxxxxxxxxxx
   S: ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@xxxxxxxxxxx
   S: ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@xxxxxxxxxxx
   S: DTSTAMP:19970611T190000Z
   S: DTSTART:19970701T180000Z
   S: DTEND:19970701T183000Z
   S: SUMMARY:Phone Conference
   S: UID:calsvr.example.com-8739701987387771
   S: ATTACH:cid:123456789@xxxxxxxxxxx
   S: SEQUENCE:0
   S: STATUS:CONFIRMED
   S: END:VEVENT
   S: END:VCALENDAR
   S: 
   S: --boundary-example-1
   S: Content-Type: application/msword; name="FieldReport.doc"
   S: Content-Transfer-Encoding: base64
   S: Content-Disposition: inline; filename="FieldReport.doc"
   S: Content-ID: <123456789@xxxxxxxxxxx>
   S: 
   S: 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA
   S: AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////
   S: 
   S: --boundary-example-1--

> In the next example, multipart negotiatiotian failed, so the CS can't
> use multipart. The attachment is converted to inline.

   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.0
   C: PRODID:-//someone's prodid
   C: CMD:SEARCH
   C: TARGET:relcal2
   C: BEGIN:VQUERY
   C: QUERY:SELECT * FROM VEVENT WHERE ....
   C: END:VQUERY
   C: END:VCALENDAR

   S: Content-Type: text/calendar
   S: 
   S: BEGIN:VCALENDAR
   S: PRODID:-//ACME/DesktopCalendar//EN
   S: METHOD:REQUEST
   S: VERSION:2.0
   S: BEGIN:VEVENT
   S: ORGANIZER:mailto:foo1@xxxxxxxxxxx
   S: ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@xxxxxxxxxxx
   S: ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@xxxxxxxxxxx
   S: DTSTAMP:19970611T190000Z
   S: DTSTART:19970701T180000Z
   S: DTEND:19970701T183000Z
   S: SUMMARY:Phone Conference
   S: UID:calsvr.example.com-8739701987387771
   S: ATTACH;ENCODING=base64;FMTTYPE=application/msword;VALUE=BINARY:
   S:  0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA
   S:  AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////
   S: SEQUENCE:0
   S: STATUS:CONFIRMED
   S: END:VEVENT
   S: END:VCALENDAR

> In the next example, the CS saved the ATTACHment on an external store:

   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.0
   C: PRODID:-//someone's prodid
   C: CMD:SEARCH
   C: TARGET:relcal2
   C: BEGIN:VQUERY
   C: QUERY:SELECT * FROM VEVENT WHERE ....
   C: END:VQUERY
   C: END:VCALENDAR

   S: Content-Type: text/calendar
   S: 
   S: BEGIN:VCALENDAR
   S: PRODID:-//ACME/DesktopCalendar//EN
   S: METHOD:REQUEST
   S: VERSION:2.0
   S: BEGIN:VEVENT
   S: ORGANIZER:mailto:foo1@xxxxxxxxxxx
   S: ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@xxxxxxxxxxx
   S: ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@xxxxxxxxxxx
   S: DTSTAMP:19970611T190000Z
   S: DTSTART:19970701T180000Z
   S: DTEND:19970701T183000Z
   S: SUMMARY:Phone Conference
   S: UID:calsvr.example.com-8739701987387771
   S: ATTACH;FMTTYPE=application/msword:
   S:  webdav://example.com/calsvr.example.com-8739701987387771
   S: SEQUENCE:0
   S: STATUS:CONFIRMED
   S: END:VEVENT
   S: END:VCALENDAR








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

 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.

> [note: I propose this change from my original text.]
> If data can be sent in different forms, it is advisable to send it
> as text/calendar. In particular, most commands SHOULD 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

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

>  This is done by sending the GET-CAPABILITY command and checking
>  for the values of the MULTIPART property. The negotiation can be
>  started by either of the endpoints.

An endpoint should assume the other endpoint 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.

>  In the example below, the CS supports multipart/related in addition
>  to text/calendar. However, the CUA sent no MULTIPART property, which
>  indicates it doesn't support any, so any subsequent data exchange
>  must only use test/calendar.

C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:The CUA's PRODID
C: CMD;ID=12345:GET-CAPABILITY
C: END:VCALENDAR

S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:The CS's PRODID
S: CMD;ID=12345:REPLY
S: BEGIN:VREPLY
S: ...
S: MULTIPART:related, alternative, mixed
S: ...
S: END:VREPLY
S: END:VCALENDAR

S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0
S: PRODID:The CS's PRODID
S: CMD;ID=12346:GET-CAPABILITY
S: END:VCALENDAR

C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:The CUA's PRODID
C: CMD;ID=12345:REPLY
C: BEGIN:VREPLY
C: ...
C: ...
C: END:VREPLY
C: END:VCALENDAR


> [note: I initially put this in to solicit discussion. If nobody
>  cares I will remove this sentence.]
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.

> [note: this sentence generated discussion on the list, but in fact
>  it's the same issue as for any URI a CUA is unable to access, so
>  it's really just a matter of user interface - and should be removed
>  from here.]
> 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.

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. Another possibility
> would be to inline the referenced data.

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.

> In the first example, multipart was negotiated earlier, so the CS
> knows it can send multipart:

   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.0
   C: PRODID:-//someone's prodid
   C: CMD:SEARCH
   C: TARGET:relcal2
   C: BEGIN:VQUERY
   C: QUERY:SELECT * FROM VEVENT WHERE ....
   C: END:VQUERY
   C: END:VCALENDAR

   S: Content-Type: multipart/related; boundary="boundary-example-1";type=text/calendar
   S: 
   S: --boundary-example-1
   S: 
   S: Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
   S: Content-Transfer-Encoding: 7bit
   S: Content-Disposition: attachment; filename="event.vcs"
   S: 
   S: BEGIN:VCALENDAR
   S: PRODID:-//ACME/DesktopCalendar//EN
   S: METHOD:REQUEST
   S: VERSION:2.0
   S: BEGIN:VEVENT
   S: ORGANIZER:mailto:foo1@xxxxxxxxxxx
   S: ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@xxxxxxxxxxx
   S: ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@xxxxxxxxxxx
   S: DTSTAMP:19970611T190000Z
   S: DTSTART:19970701T180000Z
   S: DTEND:19970701T183000Z
   S: SUMMARY:Phone Conference
   S: UID:calsvr.example.com-8739701987387771
   S: ATTACH:cid:123456789@xxxxxxxxxxx
   S: SEQUENCE:0
   S: STATUS:CONFIRMED
   S: END:VEVENT
   S: END:VCALENDAR
   S: 
   S: --boundary-example-1
   S: Content-Type: application/msword; name="FieldReport.doc"
   S: Content-Transfer-Encoding: base64
   S: Content-Disposition: inline; filename="FieldReport.doc"
   S: Content-ID: <123456789@xxxxxxxxxxx>
   S: 
   S: 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA
   S: AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////
   S: 
   S: --boundary-example-1--

> In the next example, multipart negotiatiotian failed, so the CS can't
> use multipart. The attachment is converted to inline.

   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.0
   C: PRODID:-//someone's prodid
   C: CMD:SEARCH
   C: TARGET:relcal2
   C: BEGIN:VQUERY
   C: QUERY:SELECT * FROM VEVENT WHERE ....
   C: END:VQUERY
   C: END:VCALENDAR

   S: Content-Type: text/calendar
   S: 
   S: BEGIN:VCALENDAR
   S: PRODID:-//ACME/DesktopCalendar//EN
   S: METHOD:REQUEST
   S: VERSION:2.0
   S: BEGIN:VEVENT
   S: ORGANIZER:mailto:foo1@xxxxxxxxxxx
   S: ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@xxxxxxxxxxx
   S: ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@xxxxxxxxxxx
   S: DTSTAMP:19970611T190000Z
   S: DTSTART:19970701T180000Z
   S: DTEND:19970701T183000Z
   S: SUMMARY:Phone Conference
   S: UID:calsvr.example.com-8739701987387771
   S: ATTACH;ENCODING=base64;FMTTYPE=application/msword;VALUE=BINARY:
   S:  0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA
   S:  AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////
   S: SEQUENCE:0
   S: STATUS:CONFIRMED
   S: END:VEVENT
   S: END:VCALENDAR

> In the next example, the CS saved the ATTACHment on an external store:

   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.0
   C: PRODID:-//someone's prodid
   C: CMD:SEARCH
   C: TARGET:relcal2
   C: BEGIN:VQUERY
   C: QUERY:SELECT * FROM VEVENT WHERE ....
   C: END:VQUERY
   C: END:VCALENDAR

   S: Content-Type: text/calendar
   S: 
   S: BEGIN:VCALENDAR
   S: PRODID:-//ACME/DesktopCalendar//EN
   S: METHOD:REQUEST
   S: VERSION:2.0
   S: BEGIN:VEVENT
   S: ORGANIZER:mailto:foo1@xxxxxxxxxxx
   S: ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@xxxxxxxxxxx
   S: ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@xxxxxxxxxxx
   S: DTSTAMP:19970611T190000Z
   S: DTSTART:19970701T180000Z
   S: DTEND:19970701T183000Z
   S: SUMMARY:Phone Conference
   S: UID:calsvr.example.com-8739701987387771
   S: ATTACH;FMTTYPE=application/msword:
   S:  webdav://example.com/calsvr.example.com-8739701987387771
   S: SEQUENCE:0
   S: STATUS:CONFIRMED
   S: END:VEVENT
   S: END:VCALENDAR

Follow-Ups:
- Re: Revised proposal
  - From: George Babics

Prev by Date: Re: [Fwd: How To Handle Attachments]
Next by Date: Re: Revised proposal
Previous by thread: Proposal about multipart etc
Next by thread: Re: Revised proposal
Index(es):
- Date
- Thread