[acm-tf] some thoughts on issues raised today

Dear Colleagues,

I was thinking about a couple of points made during the discussion today 
while on the train home (yes I know I should get a life but I just had 
to write it down). In particular the points about (not) introducing a 
new NIC hdl suffix (-abuse) and the need to create multiple ROLE objects 
with duplicated data for small organisations. An idea came to mind that 
addresses both these issues, fits even better within our current data 
model and is extensible.

Suppose we introduce a new attribute to the ROLE object:
role-type:      [mandatory]  [multiple]     []

and allow this initially to take one of three values:

STANDARD    All the current ROLE objects would fit with this type
ABUSE       For ROLE objects holding abuse contact data
IRT         For ROLE objects holding IRT contact data

We then add two new contact attributes "abuse-c:" and "irt-c:" 
(replacing "mnt-irt:"). These can only reference ABUSE and IRT ROLE 
object types respectively. All role based contact information is now 
held in the one object type, ROLE. All references to contact details are 
from the same type of attribute, "xxx-c:". There is no need for a new 
NIC hdl suffix. Existing ROLE objects with their current NIC hdls can be 
used for any of these roles. There is no need for a separate IRT object 
referenced by a maintainer like attribute. The ROLE object with 
"role-type: IRT" and referenced by an "irt-c:" replaces it.

The syntax for the ROLE object then becomes a superset of all the 
attributes needed for each of these roles. All these attributes can be 
defined as OPTIONAL by syntax. Their use in each type can be defined by 
business rules as one of:

REQUIRED    - must have
ALLOWED     - can have
NOT ALLOWED - can't have

Suppose we have the following superset of optional attributes for all 
role types:

abuse-mailbox:
e-mail:
phone:
irc:
url:
im:
signature:
encryption:
irt-nfy:

One example set of business rules could be:

STANDARD ROLE

REQUIRED
  e-mail:
ALLOWED
  phone:
NOT ALLOWED
  abuse-mailbox:
  irc:
  url:
  im:
  signature:
  encryption:
  irt-nfy:

ABUSE ROLE

REQUIRED
  abuse-mailbox:
ALLOWED
  phone:
  e-mail:
  irc:
  url:
  im:
NOT ALLOWED
  signature:
  encryption:
  irt-nfy:

IRT ROLE

REQUIRED
  e-mail:
  signature:
  encryption:
ALLOWED
  phone:
  irt-nfy:
NOT ALLOWED
  abuse-mailbox:
  irc:
  url:
  im:

Filtering and access control limits (ACL) could also apply differently 
to the different role types. For STANDARD and IRT ROLE objects query 
filtering (negated with the -B flag) could apply to all attributes 
containing an email address (as it does now). ACL will apply to the 
number of these role types a user queries. For the ABUSE ROLE objects 
filtering should only apply to database management attributes like 
"notify:" and "changed:". The operational specific attributes like 
"abuse-mailbox:" and "e-mail:" will not be filtered. Also no ACL will 
apply to queries for these role types.

By allowing "role-type:" to be a multiple attribute, one ROLE object can 
take on more than one role. But with the caveat that the least 
restrictive rules for a role type will apply. So for a small company 
with only one set of people who do everything, one ROLE object can be 
defined as both STANDARD and ABUSE. The business rules will be a 
composite of these two role types. No ACL will apply to queries for this 
ROLE object as it is an ABUSE role type, even though it is also a 
STANDARD role type. It becomes a user choice between convenience and 
control.

To summarise, one object type can be used to define any type of contact 
role. We currently have a need for three types. Any new type can be 
added in the future by defining a new type value. Business rules can 
define the arrangement of attributes per type from a superset of 
attributes, including any new ones added later. All contacts should be 
referenced by attributes of the format "xxx-c:" and again business rules 
can restrict the type of role these attributes can reference.

I hope this provides some helpful thoughts on these two issues and also 
takes another step in the direction of simplifying the data model.

cheers
denis