By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 2, 2009.
This document describes a Uniform Resource Name (URN) namespace for the Schema for Academia (SCHAC).
This namespace is for naming persistent resources defined by the SCHAC international activity participants, their working groups and other designated subordinates.
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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
The SCHAC international activity was born inside the TF-EMC2 middleware task force of the Trans European Research and Education Network Association. 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 personal data exchanged between educational organizations. Thus, the SCHAC schema was defined with input from all participants national person schemas. (TERENA TF-EMC2, “SCHAC activity web site,” .)
SCHAC does not supplant other person schemas such as organizationalPerson  (Sciberras, A., “Lightweight Directory Access Protocol (LDAP): Schema for User Applications,” June 2006.), inetOrgPerson  (Smith, M., “Definition of the inetOrgPerson LDAP Object Class,” April 2000.) or eduPerson  (MACE-Dir, “eduPerson Object Class Specification,” December 2007.), it extends those where needed for the pourposes of Higher Education outside the United States. This characteristic has made SCHAC, originally an European effort, useful for groups outside Europe.
- Namespace ID:
- Registration Information:
Registration Version Number 1
Registration Date: 2008-11-07
- Registrant of the namespace:
European Committee for Academic Middleware
ATTN: Licia Florio
Contact: Victoriano Giralt
Affiliation: University of Malaga
Central Computing Facility
Blvd. Louis Pasteur, 33
Campus de Teatinos
Phone: +34 95 213 2366
- Syntactic structure:
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" (Moats, R., “URN Syntax,” May 1997.). 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 4234 (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” October 2005.)):
- SCHAC-NSS = 1*(subStChar) 0*(":" 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:
- 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 their branch of the naming tree.
- 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 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. Each country with a representative in SCHAC will be invited to designate a naming authority. Country specific namespaces based on the country Internet TLD  (IANA, “Country 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 DNS name will be used as prefix.
- URNs intended for values of SCHAC attributes will include the attribute name immediately after the NSS prefix, before any geographical namespace delegation, such as any string can convey information about the attribute for which it is a value. For example, values for schacUserStatus, will be of the from:
- urn:schac:UserStatus:int: urn:schac:UserStatus:au: or urn:schac:UserStatus:terena.org
- 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.
- Institutions and communities affiliated with SCHAC participants may request that they be granted subordinate naming authority status. Uniqueness of this namespaces under each country authority will be based on the requestors Internet DNS domain name. This subordination procedure SHOULD be carried along the delegation chain, i.e., all entities that receive a delegated namespace MUST have a valid DNS name 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.
- 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:
TERENA will maintain a registry of all SCHAC assigned URN values, both final and for delegation, on its Web site: https://www.terena.org/urn 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 an HTTPS link that presents a server certificate by a recognized CA, that does not produce an alert in the user's browser.
- 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://www.terena.org/urn 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.
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.
Registration of an 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 XMLORG namespace (RFC 3120)  (Best, K. and N. Walsh, “A URN Namespace for XML.org,” June 2001.), or the more tightly controlled OASIS namespace (RFC 3121)  (Best, K. and N. Walsh, “A URN Namespace for OASIS,” June 2001.).
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 namespace but the SCHAC development is done outside MACE activity scope and thus the attributes and values do not belong into 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.
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.
Some of the already defined SCHAC attribute values have been assigned URNs under the urn:mace:terena.org namespace. This values will enter a deprecation cycle, with clear indication of them being replaced by values under the new namespace once it is assigned. Anyhow, RFC 3406  (Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, “Uniform Resource Names (URN) Namespace Definition Mechanisms,” October 2002.) (which replaced RFC 2611) includes an explicit statement that two or more URNs may point to the same resource.
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 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 make use of the SCHAC namespace.
After the establishment of the SCHAC namespace, TERENA will, as soon as practical, establish a registry service (analogously to other distributed pan-European services, like EduROAM, PerfSONAR, etc.) for the namespace clients.
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an RFC.
|||Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).|
|||Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” RFC 4234, October 2005 (TXT, HTML, XML).|
|||TERENA TF-EMC2, “SCHAC activity web site.”|
|||Sciberras, A., “Lightweight Directory Access Protocol (LDAP): Schema for User Applications,” RFC 4519, June 2006 (TXT).|
|||Smith, M., “Definition of the inetOrgPerson LDAP Object Class,” RFC 2798, April 2000 (TXT).|
|||MACE-Dir, “eduPerson Object Class Specification,” December 2007.|
|||Moats, R., “URN Syntax,” RFC 2141, May 1997 (TXT, HTML, XML).|
|||IANA, “Country TLDs.”|
|||Best, K. and N. Walsh, “A URN Namespace for XML.org,” RFC 3120, June 2001 (TXT).|
|||Best, K. and N. Walsh, “A URN Namespace for OASIS,” RFC 3121, June 2001 (TXT).|
|||Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, “Uniform Resource Names (URN) Namespace Definition Mechanisms,” BCP 66, RFC 3406, October 2002 (TXT).|
|Victoriano Giralt M.D.|
|University of Malaga|
|Avd. Cervantes, 3|
|Malaga, Malaga E-29071|
|Dr. Rodney McDuff|
|The University of Queensland|
Copyright © The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com.