RFC 4324
Calendar Access Protocol (CAP)
Pages: 131
Experimental
Experimental
Part 5 of 5 – Pages 120 to 131
11. Object Registration
This section provides the process for registration of new or modified properties, parameters, commands, or other modifications, additions, or deletions to objects.11.1. Registration of New and Modified Entities
New objects are registered by the publication of an IETF Request for Comment (RFC). Changes to objects are registered by the publication of a revision to the RFC in a new RFC.11.2. Post the Item Definition
The object description MUST be posted to the new object discussion list: ietf-calendar@imc.org.11.3. Allow a Comment Period
Discussion on a new object MUST be allowed to take place on the list for a minimum of two weeks. Consensus MUST be reached on the object before proceeding to the next step.11.4. Release a New RFC
The new object will be submitted for publication like any other Internet Draft requesting RFC status.12. BEEP and CAP
12.1. BEEP Profile Registration
BEEP replies will be one-to-one (1:1 MSG/RPY) if possible, and one- to-many (1:many MSG/ANS) when the "TARGET" property value changes. No more than one "TARGET" property value is allowed per reply. Profile Identification: specify a [URI] that authoritatively identifies this profile. http://iana.org/beep/cap/1.0 Message Exchanged during Channel Creation:
CUAs SHOULD supply the BEEP "localize" attributes in the BEEP
"greeting" messages.
CSs SHOULD supply the BEEP "localize" attributes in the BEEP
"greeting" messages.
CUAs SHOULD supply the BEEP "serverName" attribute at channel
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 not support virtual hosting may ignore the BEEP "serverName"
attribute.
Messages starting one-to-one exchanges:
The initial message, after authentication in each direction, MUST
be a single "text/calendar" object containing a CAP "CAPABILITY"
CMD. It must not be part of a MIME multipart message.
After the initial message, a BEEP "MSG" may contain one or more
MIME objects (at least one of which MUST be "text/calendar"), and
each "text/calendar" MIME object MUST contain a CAP "CMD"
property.
Multiple iCalendar objects may be sent in a single BEEP message
either by representing them as separate MIME text/calendar parts
contained within a MIME multipart/mixed part or by simple
concatenation within a single text/calendar MIME object.
In either case, all iCalendar objects that are transmitted
together must have the same TARGET property.
The sending of multipart MIME entities over BEEP is not permitted
for CAP unless the other endpoint has indicated its ability to
accept them via the appropriate CAPABILITY.
Messages in positive replies:
After the initial message, a BEEP "RPY" may contain one or more
MIME objects (at least one of which MUST be "text/calendar"), and
each "text/calendar" MIME object MUST contain a CAP "CMD"
property. All "text/calendar" MIME objects in a single BEEP "RPY"
messages MUST have the same "TARGET" property value.
Multiple iCalendar objects may be sent in a single BEEP message by
either representing them as separate MIME text/calendar parts
contained within a MIME multipart/mixed part or by simple
concatenation within a single text/calendar MIME object.
In either case, all iCalendar objects transmitted together must
have the same TARGET property.
Sending multipart MIME entities over BEEP is not permitted for CAP
unless the other endpoint has indicated its ability to accept them
via the appropriate CAPABILITY.
Messages in negative replies:
Will contain any valid "text/calendar" MIME object that contains
CAP "REQUEST-STATUS" property and a CAP "CMD" property with a
property value of "REPLY". And where the CS has determined the
requested operation to be a fatal error. And when the CS has
performed NO operation that effected the contents of any part of
the CS or any calendar controlled by the CS.
Messages in one-to-many exchanges:
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 "text/calendar" MIME object MUST contain a CAP "CMD"
property.
The BEEP "MSG" messages can only contain MIME "multipart" MIME
objects if the other endpoint has received a CAP "CAPABILITY"
indicating the other endpoint supports multipart MIME objects.
This does not prevent the endpoint from sending multiple [iCAL]
'icalobject' objects in a single BEEP "MSG" so long as all of them
have the same "TARGET" property value.
Multiple iCalendar objects may be sent in a single BEEP message by
either representing them as separate MIME text/calendar parts
contained within a MIME multipart/mixed part or by simple
concatenation within a single text/calendar MIME object.
In either case, all iCalendar objects transmitted together must
have the same TARGET property.
The sending of multipart MIME entities over BEEP is not permitted
for CAP unless the other endpoint has indicated its ability to
accept them via the appropriate CAPABILITY.
Message Syntax:
They are CAP "text/calendar" MIME objects as specified in this
memo.
Message Semantics:
As defined in this memo.
12.2. BEEP Exchange Styles
[BEEP] defines three styles of message exchange:
MSG/ANS,ANS,...,NUL - For one to many exchanges.
MSG/RPY - For one to one exchanges.
MSG/ERR - For requests the cannot be processed due to an error.
A CAP request targeted at more than one container MAY use a one- to-
many exchange with a distinct answer associated with each target. A
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
an error condition prevents the execution of the request on all the
targeted calendars.
12.3. BEEP Connection Details
All CAP communications must be done securely, 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, advertises the CAP
profiles that are supported, and replies 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
Each channel must be authenticated before work can start, but
starting a channel involves authentication. Any SASL profile may be
included, for example:
<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: <profile uri='http://iana.org/beep/SASL/ANONYMOUS'/>
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: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'/>
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 the start command to
include the initial data transfer. This reduces the number of round
trips to initiate a CAP session.
13. IANA Considerations
This memo defines IANA-registered extensions to the attributes
defined by iCalendar, as defined in [iCAL], and [iTIP].
IANA registration proposals for iCalendar and [iTIP] are to be mailed
to the registration agent for the "text/calendar" [MIME] content-
type, <MAILTO: ietf-calendar@imc.org> using the format defined in
section 7 of [iCAL].
The the IANA has registered the profile specified in Section 12.1,
and has selected an IANA-specific URI: http://iana.org/beep/cap/1.0.
14. Security Considerations
Access rights should be granted cautiously. Without careful
planning, it is possible to open up access to a greater degree than
desired.
The "IDENTIFY" command should be carefully implemented. If it is
done incorrectly, UPNs may gain access as other, unintended, UPNs.
The "IDENTIFY" command may not chain; that is, the identity is always
validated against the original UPN and not the new UPN.
Since CAP is a profile of [BEEP], consult [BEEP]'s Section 9 for a
discussion of BEEP-specific security issues.
There are risks of allowing anonymous UPNs to deposit REQUEST and
REFRESH objects (calendar spam and denial-of-service, for example).
Implementations should consider methods to restrict anonymous
requests to within acceptable usages.
CS implementations might consider automatically creating VCARs that
allow CAP ATTENDEEs in booked objects to deposit REFRESH and REPLY
objects for those UIDs if they otherwise do not have access rather
then opening up world access. And they may also consider allowing
COUNTER objects for those ATTENDEEs.
When an object is booked by a CUA ,the CS reply may wish to include
warning messages to the CUA for ATTENDEEs that have CAP urls that do
not have local UPNs as those ATTENDEES may be unable to REPLY or
REFRESH. Some CSs may wish this to be an error.
Although service provisioning is a policy matter, at a minimum, all
implementations must provide the following tuning profiles:
o for authentication: http://iana.org/beep/SASL/DIGEST-MD5
o for confidentiality: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher)
o for both: http://iana.org/beep/TLS (using the
TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side
certificates)
Appendix A. Acknowledgements
The following individuals were major contributors to the drafting and discussion of this memo, and they are greatly appreciated: Alan Davies, Andrea Campi, Andre Courtemanche, Andrew Davison, Anil Srivastava, ArentJan Banck, Arnaud Quillaud, Benjamin Sonntag, Bernard Desruisseaux, Bertrand Guiheneuf, Bob Mahoney, Bob Morgan, Bruce Kahn, Chris Dudding, Chris Olds, Christopher Apple, Cortlandt Winters, Craig Johnson, Cyrus Daboo, Damon Chaplin, Dan Hickman, Dan Kohn, Dan Winship, Darryl Champagne, David C. Thewlis, David Nicol, David Nusbaum, David West, Derik Stenerson, Eric R. Plamondon, Frank Dawson, Frank Nitsch, Gary Frederick, Gary McGath, Gilles Fortin, Graham Gilmore, Greg Barnes, Greg FitzPatrick, Harald Alvestrand, Harrie Hazewinkel, Helge Hess, Jagan Garimella, Jay Parker, Jim Ray, Jim Smith, Joerg Reichelt, John Berthels, John Smith, John Stracke, Jonathan Lennox, JP Rosevear, Karen Chu, Katie Capps Parlante, Kees Cook, Ken Crawford, Ki Wong, Lars Eggert, Lata Kannan, Lawrence Greenfield, Libby Miller, Lisa Dusseault, Lyndon Nerenberg, Mark Davidson, Mark Paterson, Mark Smith, Mark Swanson, Mark Tearle, Marshall Rose, Martijn van Beers, Martin Jackson, Matthias Laabs, Max 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, Paul Hill, and Yael Shaham-Gafni.Appendix B. References
Appendix B.1. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [BEEP] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [BEEPTCP] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001. [BEEPGUIDE] Rose, M., "BEEP, The Definitive Guide", ISBN 0-596- 00244-0, O'Reilly & Associates, Inc.
[GUIDE] Mahoney, B., Babics, G., and A. Taler, "Guide to Internet Calendaring", RFC 3283, June 2002. [iCAL] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998. [iTIP] Silverberg, S., Mansour, S., Dawson, F., and R. Hopson, "iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries", RFC 2446, November 1998. [iMIP] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 2447, November 1998. [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.Appendix B.2. Informative References
[CHARREG] Freed, N. and J. Postel, "IANA Charset Registration Procedures", RFC 2278, January 1998. [CHARPOL] Alvestrand, H., "IETF Policy on Character Sets and Languages", RFC 2277, January 1998. [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001. [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [SQL92] "Database Language SQL", ANSI/ISO/IEC 9075: 1992, aka ANSI X3.135-1992, aka FIPS PUB 127-2 [SQLCOM] ANSI/ISO/IEC 9075:1992/TC-1-1995, Technical corrigendum 1 to ISO/IEC 9075: 1992, also adopted as Amendment 1 to ANSI X3.135.1992 [URLGUIDE] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, "Guidelines for new URL Schemes", RFC 2718, November 1999.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 3986, January 2005. [URL] Berners-Lee, T, Masinter, L., and M. McCahil, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [X509CRL] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
Authors' Addresses
Doug Royer IntelliCal, LLC 267 Kentlands Blvd. #3041 Gaithersburg, MD 20878 US Phone: +1-866-594-8574 Fax: +1-866-594-8574 EMail: Doug@IntelliCal.com URI: http://Royer.com George Babics Oracle 600 Blvd. de Maisonneuve West Suite 1900 Montreal, Quebec H3A 3J2 CA Phone: +1-514-905-8694 EMail: george.babics@oracle.com Steve Mansour eBay 2145 Hamilton Avenue San Jose, CA 95125 USA Phone: +1-408-376-8817 EMail: smansour@ebay.com
Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.