<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type = 'text/xsl' href = 'file:///Users/vic/Desktop/RFC/xml2rfc-1.33/rfc2629.xslt' ?>
<!-- edited with MlView 0.8 (http://www.mlview.org/) and Vim
by Victoriano Giralt-->
<?rfc sortrefs="yes"?>
<?rfc symrefs="no"?>
<rfc docName="draft-giralt-schac-ns-05" category="info" ipr="trust200902" lang="en">
  <front>
    <title abbrev="SCHAC URN Namespace">
      Definition of a Uniform Resource Name (URN) Namespace
      for the Schema for Academia (SCHAC)
    </title>
    <author fullname="Victoriano Giralt M.D." initials="V." surname="Giralt">
      <organization abbrev="Univ. Malaga">
        University of Malaga
      </organization>
      <address>
        <postal>
          <street>Avd. Cervantes, 2</street>
          <city>Malaga</city>
          <code>E-29071</code>
          <region>Malaga</region>
          <country>Spain</country>
        </postal>
        <phone>+34-95-213-2366</phone>
        <email> victoriano@uma.es </email>
        <uri>http://www.uma.es/</uri>
      </address>
    </author>
    <author fullname="Dr. Rodney McDuff" initials="R." surname="McDuff">
      <organization abbrev="Univ. Queensland">
        The University of Queensland
      </organization>
      <address>
        <email>r.mcduff@uq.edu.au</email>
        <uri>http://www.uq.edu.au/</uri>
      </address>
    </author>
    <date day="18" month="May" year="2011"/>
    <abstract>
      <t>
        This document describes a Uniform Resource Name (URN)
        namespace for the Schema for Academia  (SCHAC). 
      </t>
      <t>
	The namespace described in this document is for naming persistent
        resources defined by the SCHAC participants internationally, their
        working groups, and other designated subordinates.  The main use of
        this namespace will be for the creation of controlled vocabulary values
        for attributes in the SCHAC schema.  These values will be associated
        with particular instances of persons or objects belonging to any of
        the SCHAC object classes.
      </t>
    </abstract>
    <note title="Requirements Language">
      <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 RFC 2119<xref target="RFC2119"/>.
      </t>
    </note>
  </front>
  <middle>
    <section title="Introduction" anchor="intro">
      <t>
	The Schema for Academia (SCHAC) international activity was born
	inside the Task Force on European Middleware Coordination and
	Collaboration (TF-EMC2) of the Trans-European Research and Education
	Network Association (TERENA)<xref target="TERENA"/>. The initial
	aim of SCHAC was to harmonise the disjoint person schemas of the
	participating countries in order to have a common way for expressing
	data about persons, exchanged between educational organizations.
	SCHAC, as other person schemas, is designed to ease the sharing of
	information about a given individual between parties, mostly,
        but not limited to, educational and research institutions. The main
        aims of this sharing are: to provide resources to individuals and to
        allow said individuals to move, virtually and physically, between
        such institutions. Thus, the SCHAC schema was defined with input
        from all participants' national person schemas<xref target="SCHAC"/>.
      </t>
      <t>
        SCHAC does not supplant other person schemas such as
        organizationalPerson <xref target="RFC4519"/>,
        inetOrgPerson <xref target="RFC2798"/> or 
        eduPerson <xref target="EP"/>, 
        it extends those where needed for the purposes of
        Higher Education outside the United States.
        This characteristic has made SCHAC, originally
        an European effort, useful for groups outside Europe.
      </t>
    </section>
    <section title="Specification Template">
      <t>
        <list style="hanging"><t hangText="Namespace ID:">
            <vspace blankLines="1"/>
            schac
            <vspace blankLines="1"/>
          </t><t hangText="Registration Information:">
            <vspace blankLines="1"/>
            Registration Version Number 1
            <vspace blankLines="1"/>
	    Registration Date: YYYY-MM-DD [RFC Editor, please replace
	    with the date of approval of this document for publication
	    as an RFC] 
            <vspace blankLines="1"/>
          </t><t hangText="Registrant of the namespace:">
            <vspace blankLines="1"/>
            European Committee for Academic Middleware (ECAM)<vspace/>
            Trans-European Research and Education Network Association (TERENA)<vspace/>
            Singel<vspace/>
            Amsterdam<vspace/>
            The Netherlands
            <vspace blankLines="1"/>
          </t><t hangText="Designated contacts:">
            <vspace blankLines="1"/>
            Contact: Licia Florio<vspace/>
            Affiliation: TERENA<vspace/>
	    Singel 468 D<vspace/>
	    Amsterdam, 1017 AW<vspace/>
	    The Netherlands
            <vspace blankLines="1"/>
            Email: florio@terena.org<vspace/>
            Phone: +31(0)20 5304488 
            <vspace blankLines="1"/>
            Contact: Victoriano Giralt<vspace/>
            Affiliation: University of Malaga<vspace/>
            Central ICT Services<vspace/>
            Blvd. Louis Pasteur, 33<vspace/>
            Campus de Teatinos<vspace/>
            29071 Malaga<vspace/>
            Spain
            <vspace blankLines="1"/>
            Email: victoriano@uma.es<vspace/>
            Phone: +34 95 213 2366
            <vspace blankLines="1"/>
          </t><t hangText="Syntactic structure:">
            <vspace blankLines="1"/>
            The Namespace Specific Strings (NSS) of all URNs assigned by
            SCHAC will conform to the syntax defined in section 2.2 of RFC
            2141, "URN Syntax"<xref target="RFC2141"/>.
            In addition, all SCHAC URN NSSs will consist of a left-to-right
            series of tokens delimited by colons. The left-to-right sequence
            of colon-delimited tokens corresponds to descending nodes in
            a tree.  To the right of the lowest naming authority node,
            there may be zero, one, or more levels of hierarchical naming
            nodes terminating in a rightmost leaf node. See the section
            below entitled "Identifier assignment" for more on the semantics
            of NSSs.  This syntax convention is captured in the following
            normative ABNF rules for SCHAC NSSs (see RFC 5234<xref target="RFC5234"/>):
          </t><t>
            <figure><artwork><![CDATA[
         SCHAC-NSS    =   1*subStChar *( ":" 1*subStChar )

         subStChar    =   trans / "%" HEXDIG HEXDIG

         trans        =   ALPHA / DIGIT / other / reserved

         other        =   "(" / ")" / "+" / "," / "-" / "." /
                          "=" / "@" / ";" / "$" /
                          "_" / "!" / "*" / "'"

         reserved     =   "/" / "?" / "#"]]></artwork></figure>
          </t><t>
            The exclusion of the colon from the list of "other" characters
            means that the colon can only occur as a delimiter between
            string tokens.  Note that this ABNF rule set guarantees that
            any valid SCHAC NSS is also a valid RFC 2141 NSS.
          </t><t hangText="Relevant ancillary documentation:">
            <vspace blankLines="1"/>
            None.
            <vspace blankLines="1"/>
          </t><t hangText="Identifier uniqueness:">
            <vspace blankLines="1"/>
            It is the responsibility of TERENA to guarantee uniqueness of
            the names of immediately subordinate naming authorities.  Each
            lower-level naming authority in turn inherits the
            responsibility of guaranteeing uniqueness of names in their
            branch of the naming tree.
            <vspace blankLines="1"/>
          </t><t hangText="Identifier persistence:">
            <vspace blankLines="1"/>
            TERENA bears ultimate responsibility for maintaining the
            usability of SCHAC URNs over time.  This responsibility MAY be
            delegated to subordinate naming authorities per the discussion
            in the section below on identifier assignment.  That section
            provides a mechanism for the delegation to be revoked in the
            case a subordinate naming authority ceases to function.
            <vspace blankLines="1"/>
          </t><t hangText="Identifier assignment:">
            <vspace blankLines="1"/>
            TERENA will create an initial series of immediately subordinate
            naming authorities, and will define a process for adding to
            that list of authorities.  Each country with a representative in SCHAC
            will be invited to designate a naming authority. Country specific 
            namespaces based on the country Internet TLD <xref target="TLDs"/>
            will be assigned then to the designated authority.
            The subordinated namespaces int and eu will remain under
            TERENA authority, controlled by the SCHAC activity members,
            for entities of global international or European interest.
            There is also the possibility of granting subordinate namespaces
            to multi-country organizations, in this case the organizational
            Internet FQDN will be used as prefix.
            <vspace blankLines="1"/>
            As an example, an European level interest entity would be any value
            related to information used in the Higher Education European Space,
            or the so called Bologna process. Such entities will belong in the
            eu subordinate namespace.
            <vspace blankLines="1"/>
            Global international entities could encompass values related to the
            Grid community or values useful both for some European and Australian
            universities. Such entities would belong in the int subordinate
            namespace.
            <vspace blankLines="1"/>
            Examples of multicountry organizations include TERENA itself or an
            association like EPI (educationalpolicy.org) that has members from
            Australia, Canada and the US.
          </t><t>  
            URNs intended for values of SCHAC attributes will include the
            attribute name immediately after the NSS prefix, before any
            geographical namespace delegation, such that any string can
            convey information about the attribute for which it is a value.
            For example, values for schacUserStatus, will be of the from:
          </t><t>
            <figure><artwork>  
              urn:schac:UserStatus:int
              urn:schac:UserStatus:au or
              urn:schac:UserStatus:terena.org
           </artwork></figure>
          </t><t>  
            Automated registry publication mechanisms will be provided if at
            all possible, based on the work on distributed URN registries
            done by the TF-EMC2 task force members.
          </t><t>  
            Institutions and communities affiliated with SCHAC participants
            may request that they be granted subordinate naming authority
            status. Uniqueness of these namespaces under country 
            authority will be based on the requestor's Internet FQDN.
            This subordination procedure SHOULD be carried along the 
            delegation chain, i.e., all entities that receive a delegated
            namespace MUST have a valid FQDN and MUST publish an Internet
            accessible URN value registry, if at all possible based on the URN
            registry mechanisms designed by the TF-EMC2 task force members.
          </t><t>  
            On at least an annual basis, TERENA will contact the liaisons or
            directors of each immediately subordinate naming authority.  If
            there is no response, or if the respondent indicates that they
            wish to relinquish naming authority, the authority over that
            branch of the tree reverts to TERENA.  This process will be
            enforced recursively by each naming authority on its
            subordinates.  This process guarantees that responsibility for
            each branch of the tree will lapse for less than one year, at
            worst, before being reclaimed by a superior authority.
          </t><t>  
            Lexical equivalence of two SCHAC namespace specific strings
            (NSSs) is defined below as an exact, case-sensitive string
            match.  TERENA will assign names of immediately subordinate
            naming authorities in lowercase only.  This forestalls the
            registration of two SCHAC-subordinate naming authorities whose
            names differ only in case. Attribute names will use the same mixed
            case format as in the schema definition.
            <vspace blankLines="1"/>
          </t><t hangText="Identifier resolution:">
            <vspace blankLines="1"/>
	    The namespace is not currently listed with a Resolution Discovery
	    System (RDS), but nothing about the namespace prohibits the future
	    definition of appropriate resolution methods or listing with an RDS.
            <vspace blankLines="1"/>
          </t><t>  
            TERENA will maintain a registry of all SCHAC assigned URN values, 
            both final and for delegation, on its Web site:
            <vspace blankLines="1"/>
            https://urnreg.terena.org/
            <vspace blankLines="1"/>
            Delegation entries will have a pointer to the registry of the
            subordinate naming authority. This SHOULD recurse down the
            delegation tree, but registries for several delegated namespaces
            MAY be maintained by a single naming authority.
          </t><t>  
	  <!--All registries MUST publish their URNs over an HTTPS link.
            Registries SHOULD consider the user interface implications of
            their choice of CA, taking into account issues like browser
	    alerts and blind trust.-->
	    All registries MUST publish their URNs using a secure web
	    site offering credentials signed by a community recognised
	    Certificate Authority (CA) and that WILL require the latest
	    secure methods for accessing a web site, that currently
	    being HTTP <xref target="RFC2616"/> over the latest version
	    of TLS <xref target="RFC5246"/>. Registries SHOULD consider
	    the user interface implications of their choice of CA,
	    taking into account issues like browser alerts and blind trust.
            <vspace blankLines="1"/>
          </t><t hangText="Lexical equivalence:">
            <vspace blankLines="1"/>
            Lexical equivalence of two SCHAC Namespace Specific Strings
            (NSSs) is defined as an exact, case-sensitive string match.
            <vspace blankLines="1"/>
          </t><t hangText="Conformance with URN syntax:">
            <vspace blankLines="1"/>
            All SCHAC NSSs fully conform to RFC 2141 syntax rules for NSSs.
            <vspace blankLines="1"/>
          </t><t hangText="Validation mechanism:">
            <vspace blankLines="1"/>
            As specified in the "Identifier resolution" section above,
            TERENA will maintain an index of all SCHAC assigned URNs on
            its Web site https://urnreg.terena.org/.
            Presence in that registry or in any subordinate one implies that
            a given URN is valid. Delegated naming authorities MUST guarantee
            that values are valid in their assigned spaces.
            <vspace blankLines="1"/>
          </t><t hangText="Scope:">
            <vspace blankLines="1"/>
            Global.
            <vspace blankLines="1"/>
          </t></list>
      </t>
    </section>
    <section title="Security Considerations" anchor="Security">
      <t>
        There are no additional security considerations beyond those normally
        associated with the use and resolution of URNs in general.
      </t>
      <t>
	<!--In order to guarantee the validity and origin of SCHAC-NSS URN values,
	    they MUST be published over HTTPS links.-->
	In order to guarantee the validity and origin of SCHAC-NSS URN values,
	they MUST be published over links pointing to secure web sites offering
	credentials signed by a community recognised Certificate Authority (CA)
	and that WILL require the latest secure methods for accessing a web
	site, that currently being HTTP <xref target="RFC2616"/> over the
	latest version of TLS <xref target="RFC5246"/>.
      </t>
    </section>
    <section title="Namespace Considerations">
      <t>
        Registration of an Namespace Identifier (NID) specific to SCHAC is
        reasonable given the following considerations:
      </t>
      <t>
        <list><t>
            SCHAC would like to assign URNs to some very fine-grained
            objects. This does not seem to be the primary intended use of
            the XMLORG namespace (RFC 3120) <xref target="RFC3120"/>,
	    or the more tightly controlled OASIS <xref target="OASIS"/>
	    namespace (RFC 3121) <xref target="RFC3121"/>.
          </t><t>
            SCHAC seeks naming autonomy. SCHAC is not a member of OASIS,
            so becoming a subordinate naming authority under the
	    OASIS URN space is not an option. There is the MACE
	    (Middleware Architecture Committee for Education)
	    <xref target="MACE"/> namespace but the SCHAC development
	    is done outside MACE activity scope and thus the attributes
	    and values do not belong into the MACE namespace. Using the
	    MACE namespace requires the SCHAC namespace to be placed
	    under one of the SCHAC participants namespace, which hinders
	    its global scope.
          </t><t>
            SCHAC will want to assign URNs to non-XML objects as well.
            That is another reason that XMLORG may not be an appropriate
            higher-level naming authority for SCHAC.
          </t></list>
      </t>
      <t>
        Some of the already defined SCHAC attribute values have been assigned 
        URNs under the urn:mace:terena.org namespace. These values will enter a 
        deprecation cycle, with clear indication of them being replaced by
        values under the new namespace once it is assigned. In any case,
        RFC 3406 <xref target="RFC3406"/> (which replaced RFC 2611) includes
        an explicit statement that two or more URNs may point to the same
        resource.
      </t>
    </section>
    <section title="Community Considerations">
      <t>
        The assignment and use of identifiers within the namespace are open,
        and the related rule is established by the SCHAC activity members.
        Registration agencies (the next level naming authorities) will be the 
	National Research and Education Networks (NRENs) and established
	organizational cross-border organizations that participate in SCHAC.
      </t>
      <t>
        It is expected that the majority of the European NRENs,
        their constituencies, participants in the Australian
        Access Federation and some other international
        activities make use of the SCHAC namespace.
      </t>
      <t>
        After the establishment of the SCHAC namespace, TERENA will
	establish a registry service (analogously to other distributed
	pan-European services, like eduroam, PerfSONAR, etc.) for the
	namespace clients. Available at: 
      </t>
    </section>
    <section title="IANA Considerations" anchor="IANA">
      <t>
        In accordance with BCP 66 <xref target="RFC3406"/>,
        IANA is asked to register the Formal URN Namespace 'schac' in
        the Registry of URN Namespaces, using the registration template
        presented in Section 2 of this document.
      </t>
    </section>
    <section title="Acknowledgments" anchor="Acknowledgments">
      <t>
        SCHAC is the result of the TERENA TF-EMC2 task force and many others
        that have contributed ideas to the development of the schema.
      </t>
      <t>
        This document has been discussed on the URN-NID list,
        with the special help of Alfred Hoenes who has thoroughly reviewed
        the documents and helped us correct errors and suggested 
        clarifications to the text.
      </t>
      <t>
	Peter Saint-Andre has also provided comments that have improved the
	overall document quality, which we herein thank him. We'd also like to
	thank Chris Lonvik for helping us express our security concerns in a
	better way. Finally, we thank other reviewers that have helped giving
	the final touchs to the text.
      </t>
      <t>
	Special thanks should go to Dyonisius Visser from the TERENA tecnical
	team for taking the time and effort required to set up the root
	instance of the namespace registry.
      </t>
    </section>
   </middle>
  <back>
    <references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.5234" ?>
<?rfc include="reference.RFC.3406"?>
    </references>
    <references title="Informative References">
<?rfc include="reference.RFC.2141"?>
<?rfc include="reference.RFC.3120"?>
<?rfc include="reference.RFC.3121"?>
<?rfc include="reference.RFC.4519"?>
<?rfc include="reference.RFC.2798"?>
<?rfc include="reference.RFC.2616"?>
<?rfc include="reference.RFC.5246"?>
      <reference anchor="TERENA">
        <front>
          <title>Trans-European Research and Education Network Association</title>
          <author>
            <organization>TERENA</organization>
            <address>
              <uri>http://www.terena.org/</uri>
            </address>
          </author>
        </front>
      </reference>
      <reference anchor="SCHAC">
        <front>
          <title>SCHAC activity web site</title>
          <author>
            <organization>TERENA TF-EMC2</organization>
            <address>
              <uri>http://www.terena.org/activities/tf-emc2/schac.html</uri>
            </address>
          </author>
        </front>
      </reference>
      <reference anchor="TLDs">
        <front>
          <title>Country TLDs</title>
          <author>
            <organization>IANA</organization>
            <address>
              <uri>http://www.iana.org/root-whois/</uri>
            </address>
          </author>
        </front>
      </reference>
      <reference anchor="OASIS">
        <front>
          <title>Organization for the Advancement of Structured Information Standards: OASIS</title>
          <author>
            <organization>OASIS</organization>
            <address>
              <uri>http://www.oasis-open.org/</uri>
            </address>
          </author>
        </front>
      </reference>
      <reference anchor="MACE">
        <front>
          <title>Middleware Architecture Committee for Education: MACE</title>
          <author>
            <organization>Internet2</organization>
            <address>
              <uri>http://www.internet2.edu/MACE/</uri>
            </address>
          </author>
        </front>
      </reference>
      <reference anchor="EP">
        <front>
          <title>eduPerson Object Class Specification</title>
          <author surname="MACE-Dir">
            <organization abbrev="Internet2">Internet2</organization>
            <address>
              <uri>http://www.nmi-edit.org/eduPerson/internet2-mace-dir-eduperson-200712.html</uri>
            </address>
          </author>
          <date month="December" year="2007"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>

