draft-ietf-calsch-cap-12.txt   draft-ietf-calsch-cap-13.txt 
Calendaring and Scheduling D. Royer Calendaring and Scheduling D. Royer
Internet-Draft INET-Consulting Internet-Draft INET-Consulting
Expires: July 12, 2004 G. Babics Expires: November 14, 2004 G. Babics
Oracle Oracle
P. Hill P. Hill
Massachusetts Institute of Massachusetts Institute of
Technology Technology
S. Mansour S. Mansour
AOL/Netscape AOL/Netscape
January 12, 2004 May 16, 2004
Calendar Access Protocol (CAP) Calendar Access Protocol (CAP)
draft-ietf-calsch-cap-12 draft-ietf-calsch-cap-13
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 12, 2004. This Internet-Draft will expire on November 14, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
The Calendar Access Protocol (CAP) is an Internet protocol described The Calendar Access Protocol (CAP) is an Internet protocol described
in this memo that permits a Calendar User (CU) to utilize a Calendar in this memo that permits a Calendar User (CU) to utilize a Calendar
User Agent (CUA) to access an [iCAL] based Calendar Store (CS). User Agent (CUA) to access an [iCAL] based Calendar Store (CS).
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Formatting Conventions . . . . . . . . . . . . . . . . . 5 1.1 Formatting Conventions . . . . . . . . . . . . . . . . . 5
1.2 Related Documents . . . . . . . . . . . . . . . . . . . 6 1.2 Related Documents . . . . . . . . . . . . . . . . . . . 6
1.3 Definitions . . . . . . . . . . . . . . . . . . . . . . 7 1.3 Definitions . . . . . . . . . . . . . . . . . . . . . . 7
2. Additions to iCalendar . . . . . . . . . . . . . . . . . 12 2. Additions to iCalendar . . . . . . . . . . . . . . . . . 12
2.1 New Value Types (summary) . . . . . . . . . . . . . . . 14 2.1 New Value Types (summary) . . . . . . . . . . . . . . . 14
2.1.1 New Parameters (summary) . . . . . . . . . . . . . . . . 14 2.1.1 New Parameters (summary) . . . . . . . . . . . . . . . . 14
2.1.2 New Properties (summary) . . . . . . . . . . . . . . . . 15 2.1.2 New or Updated Properties (summary) . . . . . . . . . . 15
2.1.3 New Components (summary) . . . . . . . . . . . . . . . . 17 2.1.3 New Components (summary) . . . . . . . . . . . . . . . . 17
2.2 Relationship of RFC-2446 (ITIP) and CAP . . . . . . . . 18 2.2 Relationship of RFC-2446 (ITIP) and CAP . . . . . . . . 18
3. CAP Design . . . . . . . . . . . . . . . . . . . . . . . 20 3. CAP Design . . . . . . . . . . . . . . . . . . . . . . . 20
3.1 System Model . . . . . . . . . . . . . . . . . . . . . . 20 3.1 System Model . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Calendar Store Object Model . . . . . . . . . . . . . . 20 3.2 Calendar Store Object Model . . . . . . . . . . . . . . 20
3.3 Protocol Model . . . . . . . . . . . . . . . . . . . . . 21 3.3 Protocol Model . . . . . . . . . . . . . . . . . . . . . 21
3.3.1 Use of BEEP, MIME and iCalendar . . . . . . . . . . . . 22 3.3.1 Use of BEEP, MIME and iCalendar . . . . . . . . . . . . 22
4. Security Model . . . . . . . . . . . . . . . . . . . . . 24 4. Security Model . . . . . . . . . . . . . . . . . . . . . 24
4.1 Calendar User and UPNs . . . . . . . . . . . . . . . . . 24 4.1 Calendar User and UPNs . . . . . . . . . . . . . . . . . 24
4.1.1 UPNs and Certificates . . . . . . . . . . . . . . . . . 24 4.1.1 UPNs and Certificates . . . . . . . . . . . . . . . . . 24
skipping to change at page 4, line 27 skipping to change at page 4, line 27
10.14 TIMEOUT Command . . . . . . . . . . . . . . . . . . . . 127 10.14 TIMEOUT Command . . . . . . . . . . . . . . . . . . . . 127
10.15 Response Codes . . . . . . . . . . . . . . . . . . . . . 128 10.15 Response Codes . . . . . . . . . . . . . . . . . . . . . 128
11. Object Registration . . . . . . . . . . . . . . . . . . 131 11. Object Registration . . . . . . . . . . . . . . . . . . 131
11.1 Registration of New and Modified Entities . . . . . . . 131 11.1 Registration of New and Modified Entities . . . . . . . 131
11.2 Post the item definition . . . . . . . . . . . . . . . . 131 11.2 Post the item definition . . . . . . . . . . . . . . . . 131
11.3 Allow a comment period . . . . . . . . . . . . . . . . . 131 11.3 Allow a comment period . . . . . . . . . . . . . . . . . 131
11.4 Release a new RFC . . . . . . . . . . . . . . . . . . . 131 11.4 Release a new RFC . . . . . . . . . . . . . . . . . . . 131
12. BEEP and CAP . . . . . . . . . . . . . . . . . . . . . . 132 12. BEEP and CAP . . . . . . . . . . . . . . . . . . . . . . 132
12.1 BEEP Profile Registration . . . . . . . . . . . . . . . 132 12.1 BEEP Profile Registration . . . . . . . . . . . . . . . 132
12.2 BEEP Exchange Styles . . . . . . . . . . . . . . . . . . 134 12.2 BEEP Exchange Styles . . . . . . . . . . . . . . . . . . 134
13. IANA Considerations . . . . . . . . . . . . . . . . . . 135 12.3 BEEP connection details . . . . . . . . . . . . . . . . 134
14. Security Considerations . . . . . . . . . . . . . . . . 136 13. IANA Considerations . . . . . . . . . . . . . . . . . . 137
Authors' Addresses . . . . . . . . . . . . . . . . . . . 137 14. Security Considerations . . . . . . . . . . . . . . . . 138
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . 139
B. Bibliography . . . . . . . . . . . . . . . . . . . . . . 140 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . 141
Intellectual Property and Copyright Statements . . . . . 142 B. Bibliography . . . . . . . . . . . . . . . . . . . . . . 142
Intellectual Property and Copyright Statements . . . . . 144
1. Introduction 1. Introduction
This document specifies how a Calendar CUA interacts with a CS to This document specifies how a Calendar CUA interacts with a CS to
manage calendar information. In particular, it specifies how to manage calendar information. In particular, it specifies how to
query, create, modify, and delete iCalendar components (e.g., events, query, create, modify, and delete iCalendar components (e.g., events,
to-dos, or daily journal entries). It further specifies how to search to-dos, or daily journal entries). It further specifies how to search
for available busy time information. Synchronization with CUAs is not for available busy time information. Synchronization with CUAs is not
covered and believed to be possible using CAP. covered and believed to be possible using CAP.
skipping to change at page 15, line 5 skipping to change at page 15, line 5
LOCAL - The "LOCAL" parameter in CAP is used to tag a property in a LOCAL - The "LOCAL" parameter in CAP is used to tag a property in a
component to signify that the component is local or to be component to signify that the component is local or to be
distributed. (Section 7.5). distributed. (Section 7.5).
LOCALIZE - The "LOCALIZE" parameter specifies the locale to be used LOCALIZE - The "LOCALIZE" parameter specifies the locale to be used
in error and warning messages. in error and warning messages.
OPTIONS - The "OPTIONS" parameter passes optional information for OPTIONS - The "OPTIONS" parameter passes optional information for
the command being sent. the command being sent.
2.1.2 New Properties (summary) 2.1.2 New or Updated Properties (summary)
ALLOW-CONFLICT - Some entries in a calendar might not be valid if ALLOW-CONFLICT - Some entries in a calendar might not be valid if
other entries were allowed to overlap the same time span. (Section other entries were allowed to overlap the same time span. (Section
8.1) 8.1)
ATT-COUNTER - When storing a "METHOD" property with the "COUNTER" ATT-COUNTER - When storing a "METHOD" property with the "COUNTER"
method, there needs to be a way to remember the "ATTENDEE" value method, there needs to be a way to remember the "ATTENDEE" value
that sent the COUNTER. (Section 8.2) that sent the COUNTER. (Section 8.2)
CAP-VERSION - The version of CAP the implementation supports. CAP-VERSION - The version of CAP the implementation supports.
skipping to change at page 132, line 10 skipping to change at page 132, line 10
11.4 Release a new RFC 11.4 Release a new RFC
The new object will be submitted for publication as any other The new object will be submitted for publication as any other
internet draft requesting RFC status. internet draft requesting RFC status.
12. BEEP and CAP 12. BEEP and CAP
12.1 BEEP Profile Registration 12.1 BEEP Profile Registration
Beep replies will be one to one (1:1 MSG/RPY) if possible and one to Beep replies will be one to one (1:1 MSG/RPY) if possible and one to
many (1:many MSG/ANS) when the TARGET changes. many (1:many MSG/ANS) when the "TARGET" property value changes. No
more than one "TARGET" property value per reply.
Profile Identification: specify a URI [10] that authoritatively Profile Identification: specify a [URI] that authoritatively
identifies this profile. identifies this profile.
http://iana.org/beep/cap/1.0 http://iana.org/beep/cap/1.0
Message Exchanged during Channel Creation: Message Exchanged during Channel Creation:
CUAs SHOULD supply the BEEP "localize" attributes in the BEEP CUAs SHOULD supply the BEEP "localize" attributes in the BEEP
"greeting" messages. "greeting" messages.
CSs SHOULD supply the BEEP "localize" attributes in the BEEP CSs SHOULD supply the BEEP "localize" attributes in the BEEP
"greeting" messages. "greeting" messages.
CUAs SHOULD supply the BEEP "serverName" attribute at channel CUAs SHOULD supply the BEEP "serverName" attribute at channel
creation time to the CS so that if the CS is performing virtual creation time to the CS so that if the CS is performing virtual
hosting the CS can determine the intended virtual host. CSs that do hosting the CS can determine the intended virtual host. CSs that do
not support virtual hosting may ignore the BEEP "serverName" not support virtual hosting may ignore the BEEP "serverName"
attribute. attribute.
Messages starting one-to-one exchanges: Messages starting one-to-one exchanges:
The initial message each direction MUST BE single "text/calendar" The initial message after authentication each direction MUST BE
object containing a CAP "CAPABILITY" CMD and must not be part of a single "text/calendar" object containing a CAP "CAPABILITY" CMD and
MIME multipart message. must not be part of a MIME multipart message.
After the initial message then a BEEP "MSG" may contain one or more After the initial message then a BEEP "MSG" may contain one or more
MIME objects at least one of which MUST be "text/calendar" and each MIME objects at least one of which MUST be "text/calendar" and each
"text/calendar" MIME object MUST contain a CAP "CMD" property. "text/calendar" MIME object MUST contain a CAP "CMD" property.
Multiple iCal objects may be sent in a single BEEP message by either Multiple iCal objects may be sent in a single BEEP message by either
representing them as separate MIME text/calendar parts contained representing them as separate MIME text/calendar parts contained
within a MIME multipart/mixed part or by simple concatenation within within a MIME multipart/mixed part or by simple concatenation within
a single text/calendar MIME object. a single text/calendar MIME object.
skipping to change at page 134, line 13 skipping to change at page 134, line 13
In either case, all iCal objects transmitted together must have the In either case, all iCal objects transmitted together must have the
same TARGET property. same TARGET property.
The sending of multipart MIME entities over BEEP is not permitted for The sending of multipart MIME entities over BEEP is not permitted for
CAP unless the other endpoint has indicated its ability to accept CAP unless the other endpoint has indicated its ability to accept
them via the appropriate CAPABILITY. them via the appropriate CAPABILITY.
Message Syntax: Message Syntax:
They are CAP "text/calendar" MIME objects as specified in this memo. They are CAP "text/calendar" MIME objects as specified in this memo.
(Remember this text will be part of CAP).
Message Semantics: Message Semantics:
As defined in this memo. (Remember this will be part of CAP). As defined in this memo.
12.2 BEEP Exchange Styles 12.2 BEEP Exchange Styles
[BEEP] defines three styles of message exchange: [BEEP] defines three styles of message exchange:
MSG/ANS,ANS,...,NUL - For one to many exchanges. MSG/ANS,ANS,...,NUL - For one to many exchanges.
MSG/RPY - For one to one exchanges. MSG/RPY - For one to one exchanges.
MSG/ERR - For requests the cannot be processed due to an error. MSG/ERR - For requests the cannot be processed due to an error.
A CAP request targeted at more than one containers, MAY use a one- A CAP request targeted at more than one containers, MAY use a one-
to-many exchange, with a distinct answer associated with each target. to-many exchange, with a distinct answer associated with each target.
CAP request targeted at a single container MAY use a one-to-one CAP request targeted at a single container MAY use a one-to-one
exchange or a one-to-many exchange. "MSG/ERR" MAY only be used when exchange or a one-to-many exchange. "MSG/ERR" MAY only be used when
an error condition prevents the execution of the request on all the an error condition prevents the execution of the request on all the
targeted calendars. targeted calendars.
12.3 BEEP connection details
All CAP communications must be done securelsecurely. So the initial
greeting includes the TLS profile.
L: <wait for incoming connection>
I: <open connection>
L: RPY 0 0 . 0 110
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri='http://iana.org/beep/TLS' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting/>
I: END
At this point the connection is secure. The TLS profile 'resets' the
connection, so it resends the greetings. And advertise the CAP
profiles supported. And reply with the profile selected (only one
profile exists at this time):
L: <wait for incoming connection>
I: <open connection>
L: RPY 0 0 . 0 110
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri='http://iana.org/beep/cap/1.0'/>
L: </greeting>
L: END
I: RPY 0 0 . 0 110
I: Content-Type: application/beep+xml
I:
I: <greeting>
I: <profile uri='http://iana.org/beep/cap/1.0'/>
I: </greeting>
I: END
Then each channel must be authenticated before work can start. Now
starting a channel involves authentication. Any SASL profile may be
included such as these:
<profile uri='http://iana.org/beep/SASL/OTP'/>
<profile uri='http://iana.org/beep/SASL/DIGEST-MD5'/>
<profile uri='http://iana.org/beep/SASL/ANONYMOUS'/>
Example of anonymous channel:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/ANONYMOUS'/>
C: </start>
S: RPY 0 1 . 221 87
S: Content-Type: application/beep+xml
S:
S:
S: END
Example of DIGEST-MD5 channel:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'/>
C: </start>
S: RPY 0 1 . 221 87
S: Content-Type: application/beep+xml
S:
S:
S: END
Piggybacking the "CAPABILITY" command. The "CAPABILITY" reply may be
included during channel start (see RFC3080, section 2.3.1.2) as BEEP
allows for the start command to include the initial data transfer.
This reduces the number of round trips to initiate a CAP session.
13. IANA Considerations 13. IANA Considerations
This memo defines IANA registered extensions to the attributes This memo defines IANA registered extensions to the attributes
defined by iCalendar, as defined in [iCAL], and [iTIP]. defined by iCalendar, as defined in [iCAL], and [iTIP].
IANA registration proposals for iCalendar and [iTIP] are to be mailed IANA registration proposals for iCalendar and [iTIP] are to be mailed
to the registration agent for the "text/calendar" [MIME] to the registration agent for the "text/calendar" [MIME]
content-type, <MAILTO: ietf-calendar@imc.org> using the format content-type, <MAILTO: ietf-calendar@imc.org> using the format
defined in section 7 of [iCAL]. defined in section 7 of [iCAL].
skipping to change at page 139, line 8 skipping to change at page 141, line 8
466 Ellis Road 466 Ellis Road
Mountain View, CA 94043 Mountain View, CA 94043
US US
Phone: +1-650-937-3351 Phone: +1-650-937-3351
EMail: sman@netscape.com EMail: sman@netscape.com
Appendix A. Acknowledgments Appendix A. Acknowledgments
The following have individuals were major contributors in the The following have individuals were major contributors in the
drafting and discussion of this memo: drafting and discussion of this memo and are greatly appreciated:
Harald Alvestrand, Christopher Apple, G. Barnes, ArentJan Banck, Alan Davies, Andrea Campi, Andre Courtemanche, Andrew Davison, Anil
Martijn van Beers, Mario Bonin, Andrea Campi, Darryl Champagne, Damon Srivastava, ArentJan Banck, Arnaud Quillaud, Benjamin Sonntag,
Chaplin, Karen Chu, Shannon Clark, Andre Courtemanche, Dave Crocker, Bernard Desruisseaux, Bertrand Guiheneuf, Bob Mahoney, Bob Morgan,
Alan Davies, Andrew Davison, Mark Davidson, Bernard Desruisseaux, Bruce Kahn, Chris Dudding, Chris Olds, Christopher Apple, Cortlandt
Frank Dawson, Pat Egen, Greg FitzPatrick, illes Fortin, Ned Freed, Winters, Craig Johnson, Cyrus Daboo, Damon Chaplin, Dan Hickman, Dan
Gary Frederick, Jagan Garimella, Graham Gilmore, Micah Gorrell, Kohn, Dan Winship, Darryl Champagne, David C. Thewlis, David Nicol,
Lawrence Greenfield, Bertrand Guiheneuf, Olivier Gutknecht, Mike David Nusbaum, David West, Derik Stenerson, Eric R. Plamondon, Frank
Hixson, Jeff Hodges, Paul Hoffman, Scott Hollenbeck, Alex Hoppman, Dawson, Frank Nitsch, Gary Frederick, Gary McGath, Gilles Fortin,
Bruce Kahn, Lata Kannan, suchet singh khalsa, Dan Kohn, Patrice Graham Gilmore, Greg Barnes, Greg FitzPatrick, Harald Alvestrand,
Lapierre, Jonathan Lennox, Lisa Lippert, Robert Lusardi, David Madeo, Harrie Hazewinkel, Helge Hess, Jagan Garimella, Jay Parker, Jim Ray,
Bob Mahoney, Murata Makoto, Gary McGath, Libby Miller, Steve Miller, Jim Smith, Joerg Reichelt, John Berthels, John Smith, John Stracke,
Bob Morgan, David Nicol, David Nusbaum, Pete O'Leary, Mark Paterson, Jonathan Lennox, JP Rosevear, Karen Chu, Katie Capps Parlante, Kees
Ralph Patterson, Eric R. Plamondon, Robert Ransdell, Jim Ray, Cook, Ken Crawford, Ki Wong, Lars Eggert, Lata Kannan, Lawrence
Marshall Rose, JP Rosevear, Paul Sharpe, Richard Shusterman, Tony Greenfield, Libby Miller, Lisa Dusseault, Lyndon Nerenberg, Mark
Small, John Smith, Benjamin Sonntag, John Stracke, Preston Davidson, Mark Paterson, Mark Smith, Mark Swanson, Mark Tearle,
Stephenson, Alexander Taler, Peter Thompson, Steve Vinter, Mark Wahl, Marshall Rose, Martijn van Beers, Martin Jackson, Matthias Laabs, Max
Dan Winship Froumentin, Micah Gorrell, Michael Fair, Mike Higginbottom, Mike
Hixson, Murata Makoto, Natalia Syracuse, Nathaniel Borenstein, Ned
Freed, Olivier Gutknecht, Patrice Lapierre, Patrice Scattolin, Paul
Hoffman, Paul Sharpe, Payod Deshpande, Pekka Pessi, Peter Thompson,
Preston Stephenson, Prometeo Sandino Roman Corral, Ralph Patterson,
Robert Lusardi, Robert Ransdell, Rob Siemborski, Satyanarayana
Vempati, Satya Vempati, Scott Hollenbeck, Seamus Garvey, Shannon
Clark, Shriram Vishwanathan, Steve Coya, Steve Mansour, Steve Miller,
Steve Vinter, Stuart Guthrie, Suchet Singh Khalsa, Ted Hardie, Tim
Hare, Timo Sirainen, Vicky Oliver, Yael Shaham-Gafni
Appendix B. Bibliography Appendix B. Bibliography
[BEEP] Rose, M., "The Block Extensible Exchange Protocol Core", [BEEP] Rose, M., "The Block Extensible Exchange Protocol Core",
ftp://ftp.isi.edu/in-notes/rfc3080.txt ftp://ftp.isi.edu/in-notes/rfc3080.txt
ftp://ftp.isi.edu/in-notes/rfc3081.txt ftp://ftp.isi.edu/in-notes/rfc3081.txt
[BEEPGUIDE] Rose, M., "BEEP, The Definitive Guide", ISBN 0-596-00244-0,
O'Reilly & Associates, Inc.
[CHARREG] Freed, N., Postel, J., "IANA Charset Registration Procedures", [CHARREG] Freed, N., Postel, J., "IANA Charset Registration Procedures",
RFC 2278, January 1998, RFC 2278, January 1998,
ftp://ftp.isi.edu/in-notes/rfc2278.txt ftp://ftp.isi.edu/in-notes/rfc2278.txt
[CHARPOL] Alvestrand, H., "IETF Policy on Character Sets and Languages", [CHARPOL] Alvestrand, H., "IETF Policy on Character Sets and Languages",
RFC 2277, January 1998, RFC 2277, January 1998,
ftp://ftp.isi.edu/in-notes/rfc2277.txt ftp://ftp.isi.edu/in-notes/rfc2277.txt
[GUIDE] Mahoney, B., Babics, G., Taler, A. "Guide to Internet [GUIDE] Mahoney, B., Babics, G., Taler, A. "Guide to Internet
Calendaring", RFC 3283, June 2002, Calendaring", RFC 3283, June 2002,
 End of changes. 16 change blocks. 
37 lines changed or deleted 137 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/