Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Document Status:  Some components are in limited deployment, and are under review for wider deployment.  Others have not yet been implemented.  See the Change Log section at the end for substantive change history.

1.  Introduction

UW Technology is incrementally extending the UW Groups Service to support new modes of group definition, more groups, more campus organizations defining groups, and more uses for groups.  A key design component is a naming plan for groups that supports the eventual campus-wide scope of the service.  It is desirable to start naming groups using a plausible scheme, even while many other aspects of the system are not yet in place.  This document specifies a group naming plan for the UW Groups Service, including syntax and top-level name components.

2.  Concepts and terminology

"NetID"-style names

This plan specifies group names that are in the style of UW NetIDs, email addresses, and web URLs.  That is, they are:  relatively short; typically meaningful to humans but not full English words; and normally writable as ASCII strings without white space.  Such identifiers are intended to fit in easily where these other identifiers typically are found.  Note, however, that the names in this plan are not themselves UW NetIDs, email addresses, or URLs/URIs; there are mappings to/from those forms in some cases.


In many cases a group name is used in a context where it is understood to be a group name in the UW infrastructure space (e.g., the "require group foo" context in UW web access control for Apache).  A short form is available for these contexts, as described in sections 3 and 4.  For more general contexts, a URI form is also defined so that each group has a globally unique name.

3.  Syntax

Group names are names in the UW NetID namespace.  The syntax defined here is a profile of the Base UW NetID syntax.



4.  UW top-level stems

UW Technology (acting as institutional group naming authority) controls the top-level stem space.  Top-level stems can be created as needed, based on discussion with stakeholders and establishment of clear definition and requirements.  Like any stem, a top-level stem must have a well-defined naming authority to manage it.


is established to name groups based on the UW NetID namespace.  Under this stem is a stem for each UW NetID, including personal and , shared types, and mailing-list idsadmin UW NetIDs, but not temp UW NetIDs or other reserved typesUW NetIDs.  For example,


is a stem whose naming authority is the person holding the personal UW NetID "rlbob".  Examples of group names based on that stem are:


The syntax of group names under the Unstructured stem is not further constrained. 

5.  Exceptions 

There may be existing practice where centrally-managed groups are named with names that do not conform to the scheme defined in sections 3 and 4.  There may also be cases where applications require group names that do not conform to this plan, but it is still appealing to manage such groups centrally.  In these cases exceptions may be granted.  Such group names must still conform to the base UW NetID syntax.  Groups named with exceptional names should still benefit from participation in group management and use operations.  Such names do not participate in the hierarchical naming scheme, however; that is they are not used as stems.  For example:


might be exceptional group names.

6.  Representation of group names as URIs

For use in URI contexts a URI namespace is assigned in UW's URN namespace:


 7.  Change Log

Note:  Changes affecting the use or deployment of the naming plan are recorded here.  Editorial changes or clarifications need not be recorded here.

2008 May 28, RL "Bob" Morgan:

  • Change section 4.1 (UW NetiD Stem) to indicate that admin netids can have these groups, but mailing list names cannot.
  • Remove "Proposal" from document name.