Calendar Access Protocol (CAP)

Voir toute la rfc dans une seule page

Télécharger le PDF

RFC 4324                Calendar Access Protocol           December 2005


         to describe such identities.  Simultaneous inclusion of the
         EmailAddress attribute in the subject distinguished name to
         support legacy implementations is deprecated but permitted.

   Since no single method of including the UPN in the certificate will
   work in all cases, CAP implementations MUST support the ability to
   configure what the mapping will be by the CS administrator.
   Implementations MAY support multiple mapping definitions, for
   example, the UPN may be found in either the subject alternative name
   field, or the UPN may be embedded in the subject distinguished name
   as an EmailAddress attribute.

   Note: If a CS or CUA is validating data received via [iMIP], if the
   "ORGANIZER" or "ATTENDEE" properties said, for example,
   "ATTENDEE;CN=Joe Random User:MAILTO:juser@example.com", then the
   email address should be checked against the UPN.  This is so the
   "ATTENDEE" property cannot be changed to something misleading like
   "ATTENDEE;CN=Joe Rictus User:MAILTO:jrictus@example.com" and have it
   pass validation.  Note that it is the email addresses that
   miscompare, the CN miscompare is irrelevant.

4.1.2.  Anonymous Users and Authentication

   Anonymous access is often desirable.  For example, an organization
   may publish calendar information that does not require any access
   control for viewing or login.  Conversely, a user may wish to view
   unrestricted calendar information without revealing their identity.

4.1.3.  User Groups

   A User Group is used to represent a collection of CUs or other UGs
   that can be referenced in VCARs.  A UG is represented in CAP as a
   UPN.  The CUA cannot distinguish between a UPN that represents a CU
   or a UG.

   UGs are expanded as necessary by the CS.  The CS MAY expand a UG
   (including nested UGs) to obtain a list of unique CUs.  Duplicate
   UPNs are filtered during expansion.

   How the UG expansion is maintained across commands is
   implementation-specific.  A UG may reference a static list of
   members, or it may represent a dynamic list.  Operations SHOULD
   recognize changes to UG membership.

   CAP does not define commands or methods for managing UGs.






Royer, et al.                 Experimental                     [Page 25]