summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6338.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6338.txt')
-rw-r--r--doc/rfc/rfc6338.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc6338.txt b/doc/rfc/rfc6338.txt
new file mode 100644
index 0000000..13b5bea
--- /dev/null
+++ b/doc/rfc/rfc6338.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) V. Giralt
+Request for Comments: 6338 Univ. Malaga
+Category: Informational R. McDuff
+ISSN: 2070-1721 Univ. Queensland
+ August 2011
+
+
+ Definition of a Uniform Resource Name (URN) Namespace
+ for the Schema for Academia (SCHAC)
+
+Abstract
+
+ This document describes a Uniform Resource Name (URN) namespace for
+ the Schema for Academia (SCHAC).
+
+ 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.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6338.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Giralt & McDuff Informational [Page 1]
+
+RFC 6338 SCHAC URN Namespace August 2011
+
+
+Copyright Notice
+
+ Copyright (c) 2011 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+1. Introduction
+
+ 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
+ Networking Association (TERENA) [6]. The initial aim of SCHAC was to
+ harmonize 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 are 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 [7].
+
+ SCHAC does not supplant other person schemas such as
+ organizationalPerson [8], inetOrgPerson [9], or eduPerson [10]; it
+ extends those where needed for the purposes of Higher Education
+ outside the United States. This characteristic has made SCHAC,
+ originally a European effort, useful for groups outside Europe.
+
+2. Requirements Language
+
+ 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 [1].
+
+
+
+
+
+
+
+
+Giralt & McDuff Informational [Page 2]
+
+RFC 6338 SCHAC URN Namespace August 2011
+
+
+3. Specification Template
+
+ Namespace ID:
+
+ schac
+
+ Registration Information:
+
+ Registration Version Number 1
+
+ Registration Date: 2011-06-22
+
+ Registrant of the namespace:
+
+ European Committee for Academic Middleware (ECAM)
+ Trans-European Research and Education Networking Association
+ (TERENA)
+ Singel
+ Amsterdam
+ The Netherlands
+
+ Designated contacts:
+
+ Contact: Licia Florio
+ Affiliation: TERENA
+ Singel 468 D
+ Amsterdam, 1017 AW
+ The Netherlands
+
+ EMail: florio@terena.org
+ Phone: +31(0)20 5304488
+
+
+ Contact: Victoriano Giralt
+ Affiliation: University of Malaga
+ Central ICT Services
+ Blvd. Louis Pasteur, 33
+ Campus de Teatinos
+ 29071 Malaga
+ Spain
+
+ EMail: victoriano@uma.es
+ Phone: +34 95 213 1415
+
+
+
+
+
+
+
+
+Giralt & McDuff Informational [Page 3]
+
+RFC 6338 SCHAC URN Namespace August 2011
+
+
+ Syntactic structure:
+
+ The Namespace Specific Strings (NSSs) of all URNs assigned by
+ SCHAC will conform to the syntax defined in Section 2.2 of
+ RFC 2141, "URN Syntax" [11]. 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 "Identifier assignment" section below for more on the
+ semantics of NSSs. This syntax convention is captured in the
+ following normative ABNF rules for SCHAC NSSs (see RFC 5234 [2]):
+
+ SCHAC-NSS = 1*subStChar *( ":" 1*subStChar )
+
+ subStChar = trans / "%" HEXDIG HEXDIG
+
+ trans = ALPHA / DIGIT / other / reserved
+
+ other = "(" / ")" / "+" / "," / "-" / "." /
+ "=" / "@" / ";" / "$" /
+ "_" / "!" / "*" / "'"
+
+ reserved = "/" / "?" / "#"
+
+ 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.
+
+ Relevant ancillary documentation:
+
+ None.
+
+ Identifier uniqueness:
+
+ 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 its branch of the naming tree.
+
+
+
+
+
+
+
+
+
+
+Giralt & McDuff Informational [Page 4]
+
+RFC 6338 SCHAC URN Namespace August 2011
+
+
+ Identifier persistence:
+
+ 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 where a subordinate
+ naming authority ceases to function.
+
+ Identifier assignment:
+
+ TERENA will create an initial series of immediately subordinate
+ naming authorities, and will define a process for adding to that
+ list of authorities. Such a list, and the policy for adding to
+ it, will be published at the root registry page. Each country
+ with a representative in SCHAC will be invited to designate a
+ naming authority. Country-specific namespaces based on the
+ country Internet Top-Level Domain (TLD) [12] will then be assigned
+ 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 Fully Qualified Domain Name
+ (FQDN) will be used as the prefix.
+
+ As an example, a 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.
+
+ Global international entities could encompass values related to
+ the Grid community or values useful both for some European and for
+ some Australian universities. Such entities would belong in the
+ int subordinate namespace.
+
+ Examples of multi-country organizations include TERENA itself or
+ an association like the Educational Policy Institute (EPI)
+ (educationalpolicy.org) that has members from Australia, Canada,
+ and the US.
+
+ 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 form:
+
+
+
+
+
+Giralt & McDuff Informational [Page 5]
+
+RFC 6338 SCHAC URN Namespace August 2011
+
+
+ urn:schac:userStatus:int
+ urn:schac:userStatus:au or
+ urn:schac:userStatus:terena.org
+
+ If at all possible, automated registry publication mechanisms will
+ be provided, based on the work on distributed URN registries done
+ by the TF-EMC2 task force members.
+
+ 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., if at all possible, all entities that receive a
+ delegated namespace MUST have a valid FQDN and MUST publish an
+ Internet accessible URN value registry, based on the URN registry
+ mechanisms designed by the TF-EMC2 task force members.
+
+ 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.
+
+ 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.
+
+ Identifier resolution:
+
+ 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.
+
+ TERENA will maintain a registry of all SCHAC-assigned URN values,
+ both final and for delegation, on its web site:
+
+ https://urnreg.terena.org/
+
+
+
+
+Giralt & McDuff Informational [Page 6]
+
+RFC 6338 SCHAC URN Namespace August 2011
+
+
+ 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.
+
+ All registries MUST publish their URNs over https links [3]. The
+ https links MUST be secured by sites offering credentials signed
+ by a SCHAC-community recognized Certification Authority (CA) using
+ the latest secure methods for accessing a web site (which at
+ present is the latest version of Transport Layer Security (TLS)
+ [4]). Registries SHOULD consider the user interface implications
+ of their choice of CA, taking into account issues like browser
+ alerts and blind trust.
+
+ Lexical equivalence:
+
+ Lexical equivalence of two SCHAC Namespace Specific Strings (NSSs)
+ is defined as an exact, case-sensitive string match.
+
+ Conformance with URN syntax:
+
+ All SCHAC NSSs fully conform to RFC 2141 syntax rules for NSSs.
+
+ Validation mechanism:
+
+ 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 registry implies that a given URN is valid. Delegated
+ naming authorities MUST guarantee that values are valid in their
+ assigned spaces.
+
+ Scope:
+
+ Global.
+
+4. Examples
+
+ The following examples are not guaranteed to be real. They are
+ listed for pedagogical reasons only.
+
+ urn:schac:personalUniqueID:es:DNI:9999999Z
+ urn:schac:personalUniqueCode:es:uma.es:codUni:061696758X
+ urn:schac:userStatus:au:uq.edu.au:service:mail:receive:disabled
+ urn:schac:personalPosition:pl:umk.pl:programmer
+
+
+
+
+
+
+Giralt & McDuff Informational [Page 7]
+
+RFC 6338 SCHAC URN Namespace August 2011
+
+
+5. Security Considerations
+
+ There are no additional security considerations beyond those normally
+ associated with the use and resolution of URNs in general.
+
+ In order to guarantee the validity and origin of SCHAC-NSS URN
+ values, they MUST be published over https links [3]. The https links
+ MUST be secured by sites offering credentials signed by a SCHAC-
+ community recognized Certification Authority (CA) using the latest
+ secure methods for accessing a web site (which at present is the
+ latest version of TLS [4]).
+
+6. Namespace Considerations
+
+ Registration of a Namespace Identifier (NID) specific to SCHAC is
+ reasonable given the following considerations:
+
+ SCHAC would like to assign URNs to some very fine-grained objects.
+ This does not seem to be the primary intended use of the XML.org
+ namespace (RFC 3120) [13], or the more tightly controlled
+ Organization for the Advancement of Structured Information
+ Standards (OASIS) [14] namespace (RFC 3121) [15].
+
+ 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) (RFC 3613) [16] namespace, but the SCHAC
+ development is done outside of the MACE activity scope; thus, the
+ attributes and values do not belong in the MACE namespace. Using
+ the MACE namespace requires that the SCHAC namespace be placed
+ under one of the SCHAC participants' namespaces, which hinders its
+ global scope.
+
+ SCHAC will want to assign URNs to non-XML objects as well. That
+ is another reason that XML.org may not be an appropriate higher-
+ level naming authority for SCHAC.
+
+ 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 a clear indication that they will be
+ replaced by values under the new namespace once it is assigned. In
+ any case, RFC 3406 [5] (which replaced RFC 2611) includes an explicit
+ statement that two or more URNs may point to the same resource.
+
+
+
+
+
+
+
+
+Giralt & McDuff Informational [Page 8]
+
+RFC 6338 SCHAC URN Namespace August 2011
+
+
+7. Community Considerations
+
+ 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.
+
+ It is expected that the majority of the European NRENs, their
+ constituencies, participants in the Australian Access Federation, and
+ some other international activities will make use of the SCHAC
+ namespace.
+
+ After the establishment of the SCHAC namespace, TERENA will establish
+ a registry service (analogously to other distributed pan-European
+ services, such as eduroam, PerfSONAR, etc.) for the namespace
+ clients. This registry will be available via the root page of the
+ namespace: https://urnreg.terena.org/. The policy for registrations
+ will be defined in documents available at the root page of the
+ registry.
+
+8. IANA Considerations
+
+ In accordance with BCP 66 [5], IANA has registered the Formal URN
+ Namespace 'schac' in the Registry of URN Namespaces, using the
+ registration template presented in Section 2 of this document.
+
+9. Acknowledgments
+
+ SCHAC is the result of the TERENA TF-EMC2 task force and many others
+ that have contributed ideas to the development of the schema.
+
+ This document was discussed on the URN-NID list, with the special
+ help of Alfred Hoenes, who thoroughly reviewed the document, helped
+ us correct errors, and suggested clarifications to the text.
+
+ Peter Saint-Andre has also provided comments that have improved the
+ overall document quality, for which we herein thank him. We'd also
+ like to thank Chris Lonvick for helping us express our security
+ concerns in a better way. Finally, we thank other reviewers that
+ have helped us to give the final touches to the text.
+
+ Special thanks should go to Dyonisius Visser from the TERENA
+ technical team for taking the time and effort required to set up the
+ root instance of the namespace registry.
+
+
+
+
+
+
+Giralt & McDuff Informational [Page 9]
+
+RFC 6338 SCHAC URN Namespace August 2011
+
+
+10. References
+
+10.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+ [3] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+ [4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
+ Protocol Version 1.2", RFC 5246, August 2008.
+
+ [5] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
+ "Uniform Resource Names (URN) Namespace Definition Mechanisms",
+ BCP 66, RFC 3406, October 2002.
+
+10.2. Informative References
+
+ [6] TERENA, "Trans-European Research and Education Networking
+ Association", <http://www.terena.org/>.
+
+ [7] TERENA TF-EMC2, "SCHAC activity web site",
+ <http://www.terena.org/activities/tf-emc2/schac.html>.
+
+ [8] Sciberras, A., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Schema for User Applications", RFC 4519, June 2006.
+
+ [9] Smith, M., "Definition of the inetOrgPerson LDAP Object Class",
+ RFC 2798, April 2000.
+
+ [10] MACE-Dir, "eduPerson Object Class Specification",
+ December 2007, <http://middleware.internet2.edu/eduperson/docs/
+ internet2-mace-dir-eduperson-200712.html>.
+
+ [11] Moats, R., "URN Syntax", RFC 2141, May 1997.
+
+ [12] IANA, "Country TLDs", <http://www.iana.org/domains/root/db/>.
+
+ [13] Best, K. and N. Walsh, "A URN Namespace for XML.org", RFC 3120,
+ June 2001.
+
+ [14] OASIS, "Organization for the Advancement of Structured
+ Information Standards: OASIS", <http://www.oasis-open.org/>.
+
+
+
+
+
+Giralt & McDuff Informational [Page 10]
+
+RFC 6338 SCHAC URN Namespace August 2011
+
+
+ [15] Best, K. and N. Walsh, "A URN Namespace for OASIS", RFC 3121,
+ June 2001.
+
+ [16] Morgan, R. and K. Hazelton, "Definition of a Uniform Resource
+ Name (URN) Namespace for the Middleware Architecture Committee
+ for Education (MACE)", RFC 3613, October 2003.
+
+Authors' Addresses
+
+ Victoriano Giralt, M.D.
+ University of Malaga
+ Avd. Cervantes, 2
+ Malaga, Malaga E-29071
+ Spain
+
+ Phone: +34-95-213-1415
+ EMail: victoriano@uma.es
+ URI: http://www.uma.es/
+
+
+ Dr. Rodney McDuff
+ The University of Queensland
+
+ EMail: r.mcduff@uq.edu.au
+ URI: http://www.uq.edu.au/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Giralt & McDuff Informational [Page 11]
+