Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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
modes of group definition, more groups, and more campus organizations
defining groups.  The general direction is stated in the UW Groups Service

One key design component is a naming scheme for groups that supports the
eventual campus-wide scope of the service.  We would like to start naming
groups using such a 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.

Using the terminology promoted in the Internet2 Grouper project, 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.

In many cases a group name is used in a context where it is understood to
be a group name (ie, the "require group foo" context in web access
control), so a short form is available for these contexts.  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

C&C (acting as institutional group naming authority) controls the
top-level stem space.  Stems can be created as needed, based on discussion
with stakeholders and establishment of clear definition and requirements.

Syntax of names under each stem can be further profiled.

4.4  UW NetID stem

A top-level stem:


represents 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):


For example,


is a stem manageable by the person owning 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).

The stem based on a shared UW NetID, eg:


would be manageable by 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.

  • No labels