Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: update link

UW group naming plan proposal
RL "Bob" Morgan

This document proposes a group naming plan for the UW Groups Service, and
provides arguments in support of the plan's design.

Section 1 describes the context of the proposal.

Section 2 lists a number of relevant "principles", some more fact-based,
others more like opinions.

Section 3 lists some design goals.

Section 4 contains the proposal.

Section 5 has some questions and open issues.

1.  Scope

C&C is incrementally extending its group management system to support new
Document Status:  The plan is in effect, though some elements are not yet implemented and some systems are in transition from older name forms.  See the Change Log section at the end for substantive change history.

1.  Introduction

UW Information Technology (UW-IT) is incrementally extending the UW Groups Service to support new modes of group definition, more groups, and more campus organizations
defining groups.  The general direction is stated in the UW Groups Service
Roadmap.One , and more uses for groups.  A key design component is a naming scheme plan for groups that supports the
eventual campus-wide scope of the service.  We would like It is desirable to start naming
groups using such a plausible scheme, even while many other aspects of the system
are not yet in place.

2.  Some principles

2.1  Lots of existing relevant group/org naming contexts

A person who manages or uses group and/or organization information at the
UW might observe their group/organization represented currently in IT
infrastructure in many different ways.  These include:

  * subdomains of  about 500, both hostnames (eg and intermediate domains (eg

  * departmental UW NetIDs/accounts:  about 5500, used for folders on, shared email accounts, shared Catalyst
    resources, etc.

  * mailman/listproc list names:  something like 6000, also part of UW
    NetID namespace, for many purposes both intra- and extra-UW.

  * subdirectories:  how many?  represent high-level
    organization of UW information space, eg admin, computing.

  * nebula groups:  a subset of departmental UW NetID space, used for
    classic group purposes in the Nebula(2) domain.

  * Catalyst groups:  over 15,000, creatable by any UW NetID holder,
    usable only within that netid's context.  Some are likely to be
    reflections of course groups.

  * course groups:  a few thousand (question) per quarter, derived from SDB
    course enrollment and instructor info

  * org codes:  several thousand (question) 10-digit values, representing UW
    organizations.  HR data associates employees with org codes in various

  * entries in the UW Office Directory:  several hundred entries listing
    contact info for UW organizations and other official functions.

Many other applications, departmental systems, and personal info stores
also contain and define group and organization info.  Unix groups in C&C
is one example.

2.2  many use contexts for group names

  * web access-control statements ("require group foo")
  * Windows AD groups
  * UNIX groups
  * view info about the group on web page
  * URI for group name wherever URIs can be used
  * email recipient (potentially)

These may imply limits on syntax, or mappings from a general namespace to
particular more limited (or more fully-qualified) namespaces to support
particular contexts.

2.3  group system should not add to multiple-name problem if possible

While some amount of variation in group/org representation is necessary
and appropriate to deal with many different contexts, clearly the average
UW person dealing with naming their group or finding out the name of some
other group of interest could be confused and saddled with lots of info to
keep in sync.  A comprehensive groups system should aim to make things
easier, not harder for UW people to accomplish their group-related goals.
In particular having a clear relationship to existing contexts, and not
imposing new name-management requirements except where necessary, are
useful goals.

2.4  groups are not orgs

It is natural to think that a groups service will support requirements for
defining campus organizations and organization structure.  Organizations
have members, and organization hierarchy might be represented by
groups-in-groups containment.  There are however many groups uses where
the relationship to organizational structure is unclear or not applicable.
Also, a comprehensive representation of campus org structure does not
exist; likely it would need to represent several distinct hierarchies for
different purposes (as has been done at some other campuses).

The observation here is that a groups system should support
organizational-based activities and representations, but should not be
burdened with being the organization system itself.  In particular, a
group entry is just a group, it should not attempt to represent "the
organization" or all of the data associated with the organization.  Nor
should the groups system have to wait on solving the org problem before it
starts deployment.

2.5  namespaces based on naming authorities

Hierarchical naming schemes are undeniably useful, especially in
distributing name-management of a single namespace across many
organizations.  In such systems it is most useful to think of the
hierarchy as a hierarchy of naming authorities.  Names in a namespace
reflect the policies of the naming authority for that namespace, and
cannot be assumed to have any particular meaning beyond that.  This
approach leads to names where intermediate nodes are recognizable active
parties rather than types or abstractions.

DNS is a good example.  The global top-level domains (.com etc) have been
very contentious because they traditionally tried to represent types of
registrants (commercial, non-profit, educational, etc).  Now gTLDs like
".net" and even new ones like ".info" have no meaning at all, they're just
spaces in which to register.  Far less contentious (though less popular)
have been the country-based TLDs, where we easily understand national
governments (via their delegates) as naming authorities.  The "edu" TLD
stabilized once it was administered by a naming authority (Educause) with
a clear set of policies.

2.6  useful to provide for both structure and freedom

In any organizational context there is a natural tension between doing
things in a structured highly-analyzed policy-driven fashion, and just
doing things.  A groups system in particular is a battleground, as it
appears to be a base for a structured approach.

It is likely that approaches will vary in different parts of the
institution and in different applications, so it's useful for a naming
plan to provide for both and let users and administrators choose.

3.  Design goals

3.1  meaningful/understandable to ordinary users

The group naming scheme must support names that are understandable to the
broad population of users, who will be creating groups, joining them, and
using them in various contexts.

While it is important that names be able to indicate intended use, it is
also necessary to recognize that the entirety of information of interest
about a group will have to be conveyed by per-group information pages, to
avoid trying to overload names with metadata such as owner, org structure,
field of use, etc.

3.2  useful in many contexts

Group names will be used in many contexts as described in 2.2.  This
implies some constraints on character set, eg spaces, to reduce the need
for quoting or string-rewriting.

3.3  limit C&C management effort in name assignment

By permitting various styles of name management, delegation of name
creation to other campus entities, being consistent with laissez-faire
UW namespace policies in other popular namespaces such as UW NetID.

3.4  support aggregation and delegation by group managers

Via hierarchical naming ...

3.5  support multiple names, name transitions

3.6  low-level design issues

3.6.1  single-part vs multi-part

Hierarchy implies multi-part names representing hierarchy.  It is useful
if the multi-partness is only significant at management time, so that in
normal use users and applications can deal with names as atomic entities
(ie, strings) rather than having to know about structure.

3.6.2  syntax and separators

Have to decide on permitted character sets, case matching, element

4.  Namespace proposal

4.1  namespaces, stems

This proposal takes the general approach of supporting hierarchical group
name assignment with ownership and delegation, but permitting the tree to
be as shallow or as deep as the institution desires, with a bias towards
ease of assignment.

  This document specifies a group naming plan for the UW Groups Service, including syntax and top-level name components.

2.  Concepts and terminology

UW Group IDs

This plan specifies group names, called UW Group IDs, 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 some important environments group names are in the same namespace as UW NetIDs.  To accommodate this, group names (at least the NetID-style group names defined in this document) must be considered to be part of the larger UW NetID namespace.  See UW NetID Namespace for more information.

This naming plan does not preclude the implementation of additional naming plans, for example a plan with longer names with a larger character set. 

Namespaces, stems, and naming authorities

It is a requirement that groups be able to be created (hence named) by potentially very large numbers of UW community members (100,000 or more).  To avoid conflicts, and to avoid the need for an approval process for each proposed group name, a hierarchical naming scheme is used.  This is similar to other environments where large-scale distributed naming is needed (e.g. DNS, file systems).

Using the terminology promoted in the Internet2 Grouper project, specific group
namespaces are referred to as "stems" (avoiding various other overloaded
terms).  A stem is created for the purpose of creating and managing groups
(and other stems) based on it, and to control access to these operations.  The entity (or entities) responsible for managing a stem is a "naming authority" for that stem.  A naming authority may delegate control of namespaces based on its stem to other naming authorities.

Names and URIs

In many cases a group name is used in a context where it is understood to
be a group name (iein the UW infrastructure space (e.g., the "require group foo" context in UW web access
control ), so a 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.

4.2  syntax

Character set:  Propose limiting name components to alphanumeric plus a
few punctuation chars:  "-", "_".  (Probably should look at various
charset specs such as URLs for guidance.)

Case:  Case insensitive matching is appealing but proves difficult to
implement uniformly.  Propose that matching is bit-for-bit.

4.3  UW top-level stems


3.  Syntax

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

A group name is a sequence of name components, by convention written left-to-right from highest-level to lowest-level naming authority. Name components are written separated by a delimiter character.

Character set: Name components are limited to lowercase letters (a-z), digits (0-9), dash ("-"), and period (".") characters.

Delimiter: The delimiter between components is underscore ("_").

Note that a particular name may be used both as the name of a group and as a stem on which other group names are based.  For example, the name


might both be used as a group (i.e., have a member list and be used in group expression contexts) and as a stem for more group names, for example:


Note: group names cannot be created without a parent stem.  Using the above example:


may not be created without first creating the group


4.  UW top-level stems

UW-IT (acting as institutional group naming authority) controls the
top-level stem space.  Stems 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.

Syntax of names under each stem can be further profiledconstrained.

4.1.  UW NetID stem

A top-level stem:


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 ids, but not
temp or reserved types):


NetID, for selected UW NetID types.  Supported UW NetID types currently include only personal and shared UW NetIDs.  For example,


is a stem manageable by whose naming authority is the person owning holding the personal UW NetID rlmorgan.
Groups can be created under that stem as the owner of that UW NetID
desires (probably with various administrative limits on number of groups,
number of members, etc).  "rlbob".  Examples of group names based on that stem are:


The stem based on a shared UW NetID , eg:


would be manageable by has as a naming authority the owners of that shared UW NetID, or their
delegates.   Capability to manage groups using that stem would be seeded
from the current owner/user data for the shared UW NetID (they wouldn't
necessarily stay in sync afterwards, though perhaps that should be an

4.4.1  Syntax of group namespace under u:

No further profile.

4.5  Other top-level stems

Note that course groups are not currently named in a global fashion since
their only venue of use, in mod_uwa, distinguishes course objects from
group objects.  Propose that course groups be named in a consistent
fashion with other groups, hence a top-level stem:


A top-level stem representing affiliations (eg faculty, staff, student)
may also be useful.

For general purposes, if the UWNetID-based namespace proves inadequate or
problematic, additional top-level stems could be created, eg


which might indicate groups with an origin external to the UW.

4.6  URIs

For use in URI contexts there would be a direct mapping of names in the
group namespace to a URI namespace:


would be another name for the u:rlmorgan:foo group.  It would be appealing
if searches on such a URI string in popular search engines resulted in a
management page describing the group.

5.  Open issues and questions

  Q:  Won't an organization like HFS be upset that it can't name its
  groups using "hfs", since the "hfs" netid is taken by a person?
  A:  Could be.  HFS has a shared netid "hfsinfo", for its main email
  address.  u:hfsinfo: might serve their purposes for a group stem, or a
  shared netid such as "uwhfs" could be created for this purpose.  If
  there is enough pushback, a new top-level namespace could be created,
  though only after considering the implications.

  Q:  Couldn't there be confusion about what a stem represents?
  Eg if H Smith owns the UW NetID "hfs" and creates uw:u:hfs:dorms:foo
  couldn't that be confused with a real dorms group?
  A:  Sure, could be, just as the owner of "hfs" may get email intended for
  the HFS organization.  Good group-information pages are needed to make
  it clear who manages groups for which purposes.  Such pages could
  restrict searches to organizational groups, for example, based on data
  that we have about netid ownership, or visually distinguish (by color,
  for example) personal groups from org groups.

  Q: Can a stem be a group also?
  A: Sure, if we want it to be.  A stem is only meaningful in the
  (eventual) group management system, to control operations on groups with
  names based on that stem.

  Q: Why colons as separators?
  A: If the group infrastructure is successful (as it has been in many of
  our peer institutions) there will be lots of groups, potentially many
  more than UW NetIDs or hostnames.  Group names can be
  used in many contexts, and colons are generally acceptable in many
  contexts.  Colons are used as separators in URNs, as one example.

is handled consistently with management of access to other resources available to that shared UW NetID.  For example, a shared UW NetID "deptxyz" would have the stem:


Examples of  group names based on that stem are:


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

4.2  UW Affiliation/Organization stem

A stem:


is established to name groups with memberships based on UW affiliations and UW organizations.  For example:


is the group whose members have the affiliation "student".  One source of affiliation names is the eduPersonAffiliation attribute defined in the eduPerson specification.  Other affiliation names might be added locally at UW.

Groups named to support UW organizations use short organization identifiers as the component following the uw_ stem.  Typically these names are used as stems for the management of potentially many groups within that organization.  As a general rule names under this stem will correspond to DNS subdomains under or that have been delegated for organizational use.  For example, if a fictional UW organization "Pavement Science" has an existing DNS subdomain "", then


could be a stem delegated to that organization, and


could be groups under that stem. 

This organizational naming plan could be superseded at some point by a more formal and comprehensive UW organization registry that would include allocation of short identifiers for these purposes. 

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

4.3  Academic Course stem

A stem:


is established to name groups with membership based on UW academic courses.   For example:


The syntax of group names in the academic course stem is:

  uwYear + uwQuarter + "-" + uwCurric + uwCrsNo + uwSectID

See UW Course Groups for definitions of the above attribute types.

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:

A group URI is formed by appending the short-form group name to that namespace.  For example, given the short-form group name:


the URI form is:

 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.





RL "Bob" Morgan

Change section 4.1 to remove application UW NetIDs, clarify examples; change section 4.2 to make examples more generic


RL "Bob" Morgan

Change section 4.2 to include support for organization names under the uw_ stem.


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.