Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4324

Calendar Access Protocol (CAP)

Pages: 131
Experimental
Part 5 of 5 – Pages 120 to 131
First   Prev   None

Top   ToC   RFC4324 - Page 120   prevText

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   ToC   RFC4324 - 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   ToC   RFC4324 - 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   ToC   RFC4324 - 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   ToC   RFC4324 - 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   ToC   RFC4324 - 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   ToC   RFC4324 - 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   ToC   RFC4324 - 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   ToC   RFC4324 - 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   ToC   RFC4324 - 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   ToC   RFC4324 - 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   ToC   RFC4324 - 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.