tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4324

 
 
 

Calendar Access Protocol (CAP)

Part 5 of 5, p. 120 to 131
Prev RFC Part

 


prevText      Top      Up      ToC       Page 120 
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:

Top      Up      ToC       Page 121 
      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.

Top      Up      ToC       Page 122 
      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.

Top      Up      ToC       Page 123 
   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):

Top      Up      ToC       Page 124 
      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

Top      Up      ToC       Page 125 
      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.

Top      Up      ToC       Page 126 
   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)

Top      Up      ToC       Page 127 
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.

Top      Up      ToC       Page 128 
   [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.

Top      Up      ToC       Page 129 
   [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.

Top      Up      ToC       Page 130 
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

Top      Up      ToC       Page 131 
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.