[acm-tf] some thoughts on issues raised today

On 15/Jun/11 21:49, Denis Walker wrote:
> 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

Very smart, elegant, and concise.  I'm no DB expert, but my reckoning
is that existing data can be converted quite smoothly for standard
roles.  Indeed, several currently defined abuse-mailbox attributes can
be kept the way they are, required updates being limited to the
addition of an abuse-c with the same handle of the role object where
the existing abuse-mailbox is defined.

If we agree on this design element, we can then focus the discussion
on attributes and their characteristics.  This seems to be a good step
forward.

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

Why is the role-type attribute itself omitted from this list?

The url attribute is rather unclear.  Do we mean "web"?  IMHO "url",
or "contact-url", is better, but it should appear /instead of/ other
contact attributes.  For example

person:          Alessandro Vesely
address:         Via Luigi Anelli, 13
address:         I-20122 Milano
address:         Italy
contact-url:     mailto:vesely at tana.it?subject=Hello
contact-url:     tel:+390236526891
contact-url:     fax:+390236527219
contact-url:     http://www.tana.it/
abuse-mailbox:   abuse at tana.it
role-type:       standard
role-type:       abuse
nic-hdl:         AV1444-RIPE
source:          RIPE # Filtered

Note how e-mail contacts may become more different from an abuse-mailbox.

> 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.

+1