Definition of a Uniform Resource Name (URN) Namespace for the Middleware Architecture Committee for Education (MACE)
A permanent naming system for education-related resources and standards.
Morgan, R. and K. Hazelton, "Definition of a Uniform Resource Name (URN) Namespace for the Middleware Architecture Committee for Education (MACE)", RFC 3613, DOI 10.17487/RFC3613, November 2003, <https://www.rfc-editor.org/info/rfc3613>.
@misc{rfc3613,
series = {Request for Comments},
number = 3613,
howpublished = {RFC 3613},
publisher = {RFC Editor},
doi = {10.17487/RFC3613},
url = {https://www.rfc-editor.org/info/rfc3613},
author = {R. Morgan and K. Hazelton},
title = {{Definition of a Uniform Resource Name (URN) Namespace for the Middleware Architecture Committee for Education (MACE)}},
pagetotal = 8,
year = 2003,
month = nov,
} RFC text
Contents
Network Working Group R. Morgan
Request for Comments: 3613 Univ. of Washington
Category: Informational K. Hazelton
Univ. of Wisconsin-Madison
October 2003
Definition of a Uniform Resource Name (URN) Namespace for the
Middleware Architecture Committee for Education (MACE)
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes a Uniform Resource Name (URN) namespace for
the Internet2 Middleware Architecture Committee for Education (MACE).
This namespace is for naming persistent resources defined by MACE,
its working groups and other designated subordinates.
1. Introduction and Community Considerations
The Internet2 Middleware Architecture Committee for Education (MACE)
produces many kinds of documents: specifications, working drafts,
object classes, schemas, stylesheets, etc. It also defines directory
attributes and controlled vocabularies for the values of some of
those attributes.
MACE wishes to provide global, distributed, persistent, location-
independent names for these resources. The Uniform Resource Name
(URN) variant of URIs meets these requirements.
MACE working groups and other MACE-affiliated groups will benefit
from the MACE URN namespace by having an easy, efficient way to
assign globally unique, persistent identifiers to resources that they
create. The nature of MACE work is that serves the needs of one or
more communities of interest. A namespace managed so as to
facilitate the creation, registration and resolution of unique,
persistent identifiers will be of great value for MACE, its
affiliates and the higher education community generally.
This URN namespace specification is for a formal namespace.
2. Specification Template
Namespace ID:
"mace"
Registration Information:
Registration Version Number 1
Registration Date: 2003-08-01
Registrant of the namespace:
Middleware Architecture Committee for Education (MACE)
ATTN: Lisa Hogeboom
Internet2
3025 Boardwalk Suite 200
Ann Arbor, MI 48108
Phone: +1 734 913 4250
Contact: Keith Hazelton
Affiliation: Univ. of Wisconsin-Madison
1210 W. Dayton St.
Madison, WI 53706
Phone: +1 608 262 0771
hazelton@doit.wisc.edu
Syntactic structure:
The Namespace Specific Strings (NSS) of all URNs assigned by MACE
will conform to the syntax defined in section 2.2 of RFC 2141,
"URN Syntax" [1]. In addition, all MACE 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 entitled "Identifier assignment" below for more on
the semantics of NSSs. This syntax convention is captured in the
following normative ABNF rules for MACE NSSs (see RFC 2234) [2]:
MACE-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
MACE NSS is also a valid RFC 2141 NSS.
Relevant ancillary documentation:
None.
Identifier uniqueness:
It is the responsibility of MACE directors 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:
MACE directors bear ultimate responsibility for maintaining the
usability of MACE 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 case a subordinate
naming authority ceases to function.
Identifier assignment:
MACE directors will create an initial series of immediately
subordinate naming authorities, and will define a process for
adding to that list of authorities. Each top-level working group
of MACE will be invited to designate a naming authority and to
suggest one or more candidate names for that authority. The
MACE-Shibboleth group, for example, might propose creating a
naming authority under "urn:mace:shib," "urn:mace:shibboleth" or
some other name.
Institutions and communities affiliated with MACE may request,
through their designated MACE liaison, that they be granted MACE-
subordinate naming authority status. They may propose candidate
names for that authority. One way for such entities to guarantee
uniqueness of their proposed name is to base it on a DNS name.
That is, if Georgetown University wished to be designated a
subordinate naming authority under MACE, the institutional MACE
liaison could propose to MACE directors that they be delegated
control over names beginning with "urn:mace:georgetown.edu".
Institutions seeking affiliation with MACE should send email to
mace-submit@internet2.edu, nominating an institutional liaison and
providing contact information for that person.
On at least an annual basis, MACE directors 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 MACE. 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 MACE namespace specific strings (NSSs)
is defined below as an exact, case-sensitive string match. MACE
will assign names of immediately subordinate naming authorities in
a case-insensitive fashion, so that there will not be two MACE-
subordinate naming authorities whose names differ only in case.
Identifier resolution:
MACE directors will maintain an index of all MACE and MACE
workgroup assigned URNs at the web site
http://middleware.internet2.edu/urn-mace/urn-mace.html. That
index will map URNs to resource identifiers or resource
specifications (e.g., protocol parameters). MACE-affiliated
naming authorities will specify how to resolve the URNs they
assign if they are resolvable.
Lexical equivalence:
Lexical equivalence of two MACE namespace specific strings (NSSs)
is defined as an exact, case-sensitive string match.
Conformance with URN syntax:
All MACE NSSs fully conform to RFC 2141 syntax rules for NSSs.
Validation mechanism:
As specified in the "Identifier resolution" section above, MACE
directors will maintain an index of all MACE and MACE workgroup
assigned URNs on its web site,
http://middleware.internet2.edu/urn-mace/urn-mace.html. Presence
in that index implies that a given URN is valid. MACE-affiliated
naming authorities will specify how to validate the URNs they
assign.
Scope:
Global.
3. Security Considerations
There are no additional security considerations beyond those normally
associated with the use and resolution of URNs in general.
4. Namespace Considerations
Registration of an NID specific to MACE is reasonable given the
following considerations:
1. MACE would like to assign URNs to some very fine-grained objects
(such as specific controlled vocabulary values of an attribute in
MACE-defined LDAP object classes). This does not seem to be the
primary intended use of the XMLORG namespace (RFC 3120) [3], let
alone the more tightly controlled OASIS namespace (RFC 3121) [4].
2. MACE seeks naming autonomy. We understand that the XMLORG
registrants left the door open to subordinate naming authorities,
"OASIS may assign portions of its XMLORG namespace for assignment
by other parties" (RFC 3120) [3], but there is no specified
process for such assignment. That would in any case mean having a
fixed XMLORG-assigned prefix on every single object to which we
assign a URN. MACE has a number of active work groups that may
well generate a growing number of subordinate naming authorities.
Moreover, MACE is not a member of OASIS, so becoming a subordinate
naming authority under the OASIS URN space is currently not an
option.
3. MACE 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 MACE.
Some MACE-developed schema and namespaces may be good candidates for
inclusion in the XMLORG registry. The fact that such an object might
already have a MACE-assigned URN shouldn't be a hindrance. Work is
in progress to update RFC 2611 [5], which includes an explicit
statement that two or more URNs may point to the same resource. A
resource with a MACE-assigned namespace-specific-string would, of
course, be given an XMLORG namespace-specific-string at the time it
enters the XMLORG registry.
5. IANA Considerations
The IANA has formally registered URN namespace 13 to MACE, within the
IANA registry of URN NIDs.
6. Normative References
[1] Moats, R., "URN Syntax", RFC 2141, May 1997.
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[3] Best, K. and N. Walsh, "A URN Namespace for XML.org", RFC 3120,
June 2001.
[4] Best, K. and N. Walsh, "A URN Namespace for OASIS", RFC 3121,
June 2001.
[5] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "URN
Namespace Definition Mechanisms", BCP 33, RFC 2611, June 1999.
7. Authors' Addresses
RL "Bob" Morgan
4545 15th Ave. NE
Seattle, WA 98105
U.S.A.
EMail: rlmorgan@washington.edu
Keith D. Hazelton
University of Wisconsin-Madison
1210 W. Dayton St.
Madison, WI 53706
U.S.A.
EMail: hazelton@doit.wisc.edu
8. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
AI ELI5
On this page
§1Why MACE Needs Persistent Names
The Internet2 Middleware Architecture Committee for Education (MACE) creates specifications, working drafts, XML schemas, stylesheets, and controlled vocabularies used by the higher education community. As these resources evolve and change locations, organizations need permanent names that point to them reliably.
A Uniform Resource Name (URN) is a type of Uniform Resource Identifier (URI) designed for exactly this purpose. Unlike a URL, which changes when a resource moves, a URN remains the same and is resolved through an infrastructure independent of any single web server. This document registers a formal URN namespace for MACE called mace.
MACE makes documents for schools. Instead of a web address that breaks when the server moves, MACE gives each document a permanent name that always works.
§2How MACE URN Names Are Structured
All MACE URNs follow the form urn:mace:colon:delimited:tokens. The tokens form a hierarchy, left to right, from highest authority to the specific resource. The syntax allows letters, digits, and special characters like hyphens, dots, and underscores, with colons used only to separate tokens.
For example, a working group might create names under urn:mace:shibboleth, and an institution might use urn:mace:georgetown.edu based on its domain name. The namespace specification conforms fully to RFC 2141 (URN Syntax), ensuring compatibility with URN resolution infrastructure.
Naming authorities at each level are responsible for ensuring uniqueness of names at their level and delegating authority downward. MACE directors maintain an index of all registered URNs on a web site for discovery and validation.
Names are like file paths: urn:mace:school:department:document. Each level is managed by the people below it, so everyone gets a unique name.
§3Assignment and Persistence
MACE directors create an initial set of immediate subordinate naming authorities and define a process for adding more. Each MACE working group designates a naming authority and proposes candidate names. Institutions can request subordinate authority status by contacting MACE through their institutional liaison.
To guarantee persistence, MACE directors contact each naming authority at least annually. If there is no response or the authority wishes to relinquish control, that branch reverts to MACE for reassignment. This process prevents orphaned branches of the namespace and ensures that responsibility for any branch lapses for less than a year.
Names are assigned case-insensitively at the top level (so two authorities will not differ only in case), and assigned names are treated as case-sensitive for all other purposes.
MACE keeps a phone tree and calls once a year. If someone moves or quits, MACE takes that branch back and finds someone new.
§4Resolution and Validation
Resolution of a MACE URN is the process of finding what resource or resource specification the URN points to. MACE maintains a central index on its web site mapping all MACE and workgroup-assigned URNs to resource identifiers or specifications. MACE-affiliated naming authorities specify how to resolve the URNs they assign.
Validation means confirming that a URN is legitimate. Presence in the MACE index implies validity. Subordinate authorities specify their own validation mechanisms. This two-level approach allows MACE to govern the overall namespace while delegating specifics to working groups and institutions.
MACE keeps a directory of all names and what they point to. When someone asks 'is this a real MACE name?', MACE checks the directory.
§5Scope and Considerations
The MACE namespace is global in scope and can assign URNs to very fine-grained objects, such as specific values in controlled vocabularies or individual XML elements. This makes it more suitable for MACE needs than broader namespaces like XMLORG, which are intended for different purposes.
MACE chose its own namespace rather than becoming a subordinate of an existing namespace because it seeks naming autonomy and wants to avoid fixed prefixes on every URN. MACE also names non-XML objects, which further justified having its own namespace.
MACE can name small things (like one field in a form) or big things (like a whole standard). It doesn't have to ask permission from other organizations.