Calendar Access Protocol (CAP)
Voir toute la rfc dans une seule page
Page : 25 / 131
Télécharger le PDF
Auteur(s) : S. Mansour
, G. Babics
, D. Royer
Classé sous : Calendar user
, Calendar user agent
, Calender store
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:firstname.lastname@example.org", 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:email@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]