Difference between revisions of "RFC3613"

From RFC-Wiki
 
Line 8: Line 8:
 
       Middleware Architecture Committee for Education (MACE)
 
       Middleware Architecture Committee for Education (MACE)
  
Status of this Memo
+
'''Status of this Memo'''
  
 
This memo provides information for the Internet community.  It does
 
This memo provides information for the Internet community.  It does
Line 14: Line 14:
 
memo is unlimited.
 
memo is unlimited.
  
Copyright Notice
+
'''Copyright Notice'''
  
 
Copyright (C) The Internet Society (2003).  All Rights Reserved.
 
Copyright (C) The Internet Society (2003).  All Rights Reserved.
  
Abstract
+
'''Abstract'''
  
 
This document describes a Uniform Resource Name (URN) namespace for
 
This document describes a Uniform Resource Name (URN) namespace for
Line 82: Line 82:
  
 
   The Namespace Specific Strings (NSS) of all URNs assigned by MACE
 
   The Namespace Specific Strings (NSS) of all URNs assigned by MACE
   will conform to the syntax defined in section 2.2 of RFC 2141,
+
   will conform to the syntax defined in section 2.2 of [[RFC2141|RFC 2141]],
 
   "URN Syntax" [1].  In addition, all MACE URN NSSs will consist of
 
   "URN Syntax" [1].  In addition, all MACE URN NSSs will consist of
 
   a left-to-right series of tokens delimited by colons.  The left-
 
   a left-to-right series of tokens delimited by colons.  The left-
Line 91: Line 91:
 
   See the section entitled "Identifier assignment" below for more on
 
   See the section entitled "Identifier assignment" below for more on
 
   the semantics of NSSs.  This syntax convention is captured in the
 
   the semantics of NSSs.  This syntax convention is captured in the
   following normative ABNF rules for MACE NSSs (see RFC 2234) [2]:
+
   following normative ABNF rules for MACE NSSs (see [[RFC2234|RFC 2234]]) [2]:
  
 
   MACE-NSS        =  1*(subStChar) 0*(":" 1*(subStChar))
 
   MACE-NSS        =  1*(subStChar) 0*(":" 1*(subStChar))
Line 110: Line 110:
 
   means that the colon can only occur as a delimiter between string
 
   means that the colon can only occur as a delimiter between string
 
   tokens.  Note that this ABNF rule set guarantees that any valid
 
   tokens.  Note that this ABNF rule set guarantees that any valid
   MACE NSS is also a valid RFC 2141 NSS.
+
   MACE NSS is also a valid [[RFC2141|RFC 2141]] NSS.
  
 
Relevant ancillary documentation:
 
Relevant ancillary documentation:
Line 191: Line 191:
 
Conformance with URN syntax:
 
Conformance with URN syntax:
  
   All MACE NSSs fully conform to RFC 2141 syntax rules for NSSs.
+
   All MACE NSSs fully conform to [[RFC2141|RFC 2141]] syntax rules for NSSs.
  
 
Validation mechanism:
 
Validation mechanism:
Line 220: Line 220:
 
   (such as specific controlled vocabulary values of an attribute in
 
   (such as specific controlled vocabulary values of an attribute in
 
   MACE-defined LDAP object classes).  This does not seem to be the
 
   MACE-defined LDAP object classes).  This does not seem to be the
   primary intended use of the XMLORG namespace (RFC 3120) [3], let
+
   primary intended use of the XMLORG namespace ([[RFC3120|RFC 3120]]) [3], let
   alone the more tightly controlled OASIS namespace (RFC 3121) [4].
+
   alone the more tightly controlled OASIS namespace ([[RFC3121|RFC 3121]]) [4].
  
 
2. MACE seeks naming autonomy.  We understand that the XMLORG
 
2. MACE seeks naming autonomy.  We understand that the XMLORG
 
   registrants left the door open to subordinate naming authorities,
 
   registrants left the door open to subordinate naming authorities,
 
   "OASIS may assign portions of its XMLORG namespace for assignment
 
   "OASIS may assign portions of its XMLORG namespace for assignment
   by other parties" (RFC 3120) [3], but there is no specified
+
   by other parties" ([[RFC3120|RFC 3120]]) [3], but there is no specified
 
   process for such assignment.  That would in any case mean having a
 
   process for such assignment.  That would in any case mean having a
 
   fixed XMLORG-assigned prefix on every single object to which we
 
   fixed XMLORG-assigned prefix on every single object to which we
Line 242: Line 242:
 
inclusion in the XMLORG registry.  The fact that such an object might
 
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
 
already have a MACE-assigned URN shouldn't be a hindrance.  Work is
in progress to update RFC 2611 [5], which includes an explicit
+
in progress to update [[RFC2611|RFC 2611]] [5], which includes an explicit
 
statement that two or more URNs may point to the same resource.  A
 
statement that two or more URNs may point to the same resource.  A
 
resource with a MACE-assigned namespace-specific-string would, of
 
resource with a MACE-assigned namespace-specific-string would, of
Line 255: Line 255:
 
== Normative References ==
 
== Normative References ==
  
[1]  Moats, R., "URN Syntax", RFC 2141, May 1997.
+
[1]  Moats, R., "URN Syntax", [[RFC2141|RFC 2141]], May 1997.
  
 
[2]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
 
[2]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
     Specifications: ABNF", RFC 2234, November 1997.
+
     Specifications: ABNF", [[RFC2234|RFC 2234]], November 1997.
  
[3]  Best, K. and N. Walsh, "A URN Namespace for XML.org", RFC 3120,
+
[3]  Best, K. and N. Walsh, "A URN Namespace for XML.org", [[RFC3120|RFC 3120]],
 
     June 2001.
 
     June 2001.
  
[4]  Best, K. and N. Walsh, "A URN Namespace for OASIS", RFC 3121,
+
[4]  Best, K. and N. Walsh, "A URN Namespace for OASIS", [[RFC3121|RFC 3121]],
 
     June 2001.
 
     June 2001.
  
 
[5]  Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "URN
 
[5]  Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, "URN
     Namespace Definition Mechanisms", BCP 33, RFC 2611, June 1999.
+
     Namespace Definition Mechanisms", [[BCP33|BCP 33]], [[RFC2611|RFC 2611]], June 1999.
  
 
== Authors' Addresses ==
 
== Authors' Addresses ==
Line 318: Line 318:
 
Funding for the RFC Editor function is currently provided by the
 
Funding for the RFC Editor function is currently provided by the
 
Internet Society.
 
Internet Society.
 +
 +
[[Category:Informational]]

Latest revision as of 05:31, 4 October 2020

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.

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.

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
  [email protected]

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
  [email protected], 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.

Security Considerations

There are no additional security considerations beyond those normally associated with the use and resolution of URNs in general.

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.

IANA Considerations

The IANA has formally registered URN namespace 13 to MACE, within the IANA registry of URN NIDs.

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.

Authors' Addresses

RL "Bob" Morgan 4545 15th Ave. NE Seattle, WA 98105 U.S.A.

EMail: [email protected]

Keith D. Hazelton University of Wisconsin-Madison 1210 W. Dayton St. Madison, WI 53706 U.S.A.

EMail: [email protected]

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.