<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC2739 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2739.xml'>
<!ENTITY RFC3339 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3339.xml'>
<!ENTITY RFC4589 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4589.xml'>
<!ENTITY RFC6350 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6350.xml'>
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<?rfc rfcedstyle="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="6"?><!-- default = 3 -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<!-- <?rfc strict="yes"?> -->
<!-- <?rfc comments="yes"?> -->
<!-- <?rfc inline="yes"?> -->

<rfc category="std" ipr='trust200902' docName='draft-vcard-objectclass-00'>
  <front>
      <title abbrev="Objectclass property for vCard">Objectclass property for vCard</title>
      <author initials="C." surname="Joy" fullname="Ciny Joy">
          <organization abbrev="Oracle">Oracle Corporation</organization>
          <address>
              <postal>
                  <street>
                      4210 Network Circle
                  </street>
                  <city>
                      Santa Clara
                  </city>
                  <region>
                      CA
                  </region>
                  <code> 95054 </code>
                  <country>
                      USA
                  </country>
              </postal>
              <email>
                  ciny.joy@oracle.com
              </email>
              <uri>
                  http://www.oracle.com/
              </uri>
          </address>
      </author>

      <author initials="C." surname="Daboo" fullname="Cyrus Daboo">
          <organization abbrev="Apple Inc.">
              Apple Inc.
          </organization>
          <address>
              <postal>
                  <street>
                      1 Infinite Loop
                  </street>
                  <city>
                      Cupertino
                  </city>
                  <region>
                      CA
                  </region>
                  <code> 95014 </code>
                  <country>
                      USA
                  </country>
              </postal>
              <email>
                  cyrus@daboo.name
              </email>
              <uri>
                  http://www.apple.com/
              </uri>
          </address>
      </author>

      <author initials="M." surname="Douglass" fullname="Michael Douglass">
          <organization abbrev="RPI">Rensselaer Polytechnic Institute</organization>
          <address>
              <postal>
                  <street>110 8th Street</street>
                  <city>Troy</city>
                  <region>NY</region>
                  <code>12180</code>
                  <country>USA</country>
              </postal>
              <email>douglm@rpi.edu</email>
              <uri>http://www.rpi.edu/</uri>
          </address>
      </author>

      <date month='January' year='2013' />
      <area>
          Applications
      </area>

      <abstract>
          <t>
            This specification describes a new property for 
            <xref target="RFC6350">vCard Format Specification</xref>
            to allow the specification of objectclasses.
          </t>
      </abstract>
  </front>

  <middle>
    <section title='Introduction'>
      <t>
        The objectclass concept is used in ldap to allow the specification
        of a set of properties which describe a given type of object. For
        example, a schedulable entity MUST contain a calendar user address
        and the absence of the AUTOSCHEDULE property implies certain defaults.
      </t>
      
      <t>
        An ldap objectclass may be of 3 kinds, structural, abstract and
        auxiliary. The vcard KIND property is equivalent to the structural
        objectclass in that a vcard can be of only one kind. The kind
        requires that certain properties be present and also defines
        defaults for absent properties. 
      </t>
      
      <t>
        The OBJECTCLASS property defined here is equivalent in many ways
        to the auxiliary objectclass in ldap. They are not 
        related to each other in some hierarchy and may overlap in their use
        of properties.
      </t>
      
      <t>
        Objectclass definitions can only specify properties which MUST, 
        SHOULD or MAY be present. They cannot disallow the use of 
        properties as these may be required by another objectclass.
      </t>
    </section>

    <section title='Conventions Used in This Document'>
      <t>
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
        document are to be interpreted as described in <xref target="RFC2119" />.
      </t>
    </section>

    <section title='Objectclass Property' anchor="objectclass_property">
      <t>
        Format and cardinality of new vCard properties are defined as described 
        in Section 3.3 of <xref target='RFC6350' />.
      </t> 
      
      <t>
        <list style="hanging">
         <t hangText="Property name:">
            OBJECTCLASS
          </t>
          <t hangText="Purpose:">
            To specify the objectclass for this vcard.
          </t>
         <t hangText="ValueType:"> 
            IANA value.
          </t>
          <t hangText="Cardinality:"> 
              *
          </t>
          <t hangText="ABNF:"> 
              OBJECTCLASS-param = any-param <vspace />
              OBJECTCLASS-value = text
            </t>
          <t hangText="Default value:">
              None.
          </t>
          <t hangText="Example value:">
              schedulable
          </t>
          <t hangText="Description:">
              This property MAY be present 1 or more times. For each occurrence
              of the property the vcard MUST conform to the specification for 
              that objectclass. 
          </t>
        </list> 
      </t>
    </section>

    <section title='Examples'>
      <t>
        These examples do not draw on any currently defined objectclass but are
        intended to indicate some uses. Properties used here may not be defined
        in any specification. 
      </t>
      
      <section title='Eduperson vcard'>
        <t>
          The eduperson ldap objectclass provides for a number of attributes
          considered useful for interaction between members of educational 
          organizations. A corresponding vcard objectclass would allow for
          better mappping of ldap directories onto a vcard representation. 
        </t>
        <figure>
          <preamble>
            The 201203 specification of the LDAP objectclass for reference. 
            Note that all attributes are MAY so would have a vcard cardinality
            of *1 or *.
          </preamble>
          <artwork>
( 1.3.6.1.4.1.5923.1.1.2
        NAME 'eduPerson'
        AUXILIARY
        MAY ( eduPersonAffiliation $
                    eduPersonNickname $
                    eduPersonOrgDN $
                    eduPersonOrgUnitDN $
                    eduPersonPrimaryAffiliation $
                    eduPersonPrincipalName $
                    eduPersonEntitlement $
                    eduPersonPrimaryOrgUnitDN $
                    eduPersonScopedAffiliation $
                    eduPersonTargetedID $
                    eduPersonAssurance)
          </artwork>
        </figure>
        <figure>
          <preamble>
            A vcard mapping would, where possible use existing vcard properties.
            Where not possible new properties could be defined. 
          </preamble>
<artwork>
     BEGIN:VCARD
     VERSION:4.0
     UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
     FN:J. Doe
     N:Doe;J.;;;
     EMAIL:jdoe@example.edu
     TEL;VALUE=uri:tel:+1-555-555-5555
     OBJECTCLASS:eduperson
     NICKNAME:Jack
     ORGDN: dc=example, dc=edu
     AFFILIATION;TYPE=primary:faculty
     AFFILIATION;TYPE=scoped:faculty@cs.example.edu
     END:VCARD
</artwork>
        </figure>
      </section>
      
      <section title='Schedulable'>
        <t>
          A schedulable entity can be scheduled for meetings (as a person) or
          for use (as a resource). For a scheduling system to be able to 
          usefully manage the schedule it needs specific information.
        </t>
        
        <t>
          At the very least there needs to be some form of calendar user address.
          It's useful to know whether requests can be auto accepted if the slot
          is available. 
        </t>
        <figure>
          <preamble>
            Building on the previous example we'll make Jack schedulable.
          </preamble>
          <artwork>
     BEGIN:VCARD
     VERSION:4.0
     UID:urn:uuid:4fbe8971-0bc3-424c-9c26-36c3e1eff6b1
     FN:J. Doe
     N:Doe;J.;;;
     EMAIL:jdoe@example.edu
     TEL;VALUE=uri:tel:+1-555-555-5555
     OBJECTCLASS:eduperson
     NICKNAME:Jack
     ORGDN: dc=example, dc=edu
     AFFILIATION;TYPE=primary:faculty
     AFFILIATION;TYPE=scoped:faculty@cs.example.edu
     OBJECTCLASS:schedulable
     CALADRURI:jdoe@example.edu
     AUTOSCHEDULE:ACCEPT-IF-FREE
     END:VCARD
</artwork>
        </figure>
      </section>
    </section>

    <section title="Security Considerations" anchor="SECURITY_CONSIDERATIONS">
      <t>
        As this document only defines a schema related property and does not refer 
        to the actual storage mechanism itself, no special security considerations 
        are required as part of this document.
      </t> 
    </section><!-- SECURITY_CONSIDERATIONS -->
  
    <section title='IANA Considerations' anchor ='iana_registry'>
      <section title='New VCard Objectclass Value Registration'>
        <t>
          New objectclass values will be defined according to the process specified
          in Section 10.2.6 of <xref target='RFC6350' />.
       </t>
      </section>
    </section>
  
    <section title='Acknowledgments'>
      <t>
        This specification is a result of discussions that took place within the 
        Calendaring and Scheduling Consortium's Resource Technical Committee. The 
        authors thank the participants of that group.
      </t>
    </section>
  </middle>

  <back>
    <references title='Normative References'>
      &RFC2119;
      &RFC2739;
      &RFC3339;
      &RFC4589;
      &RFC6350;
  
      <reference anchor="ISO.8601.2004">
        <front>
          <title>
            Data elements and interchange formats --
            Information interchange --
            Representation of dates and times
          </title>
          <author>
            <organization>
              International Organization for Standardization
            </organization>
          </author>
          <date year="2004"/>
        </front>
      </reference><!-- ISO.8601.2004-->
    </references>
  </back>

</rfc>
