It's been very quiet on the list since the frantic activity at the end of last week. I expect day-to-day reality has imposed itself. I've done some further thinking, and have reviewed the contributions last week on the db-wg list. I've tried to recognize the issues and alternatives in this message and to make proposals as straw-men for consensus. I've used a bullet-point approach, as I think no-one is likely to have time to read anything more discursive. I'll happily explain anything that people find too terse. Here goes ... Attribute name Name should be distinctive, eg: 'abuse-mailbox'; not 'e-mail' Handle Handle is upwardly scalable Handle could refer to person, role, or maintainer Value Value is necessary; if not in primary object, then indirectly Value in primary object is attractive at low end of scale Value is vulnerable to RHS-hijacking, even if not in primary object! Hint string Trailing #-comment is easiest RFC822 parens-comment as part of value is possible Qualifier to attribute name would be neat, but may be difficult to implement (eg: abuse-mailbox-{spam,security}) Proposal (1) Advertisement (sysadmin) side Use two attributes: one to hold value, the other to hold handle Use attribute 'abuse-mailbox' to hold value Use attribute name 'abuse-c' to hold indirect object handle Allow use of 'abuse-mailbox' attribute in primary object Encourage use of attribute in indirect object as best practice Support all relevant indirect objects (person, role, maintainer) in order to make it easy for sysadmins We REALLY WANT sysadmins to ADOPT this (NAFS: no apol for shout) Inheritance Implemented in query tool: design and coding resource impact Must be 'intuitive' for advertising sysadmin Two axes: by reference to handle; by containing block Priority: by reference first, but ... Proposal (2) Query side algorithm Specifies behaviour of focused query tool Sysadmins must take account when advertising in order to align query result with their intent Needs discussion: Concept Implementation: cost to implement, performance, possible pruning of search tree Given object (from inet*num, asnum, ...) and circumstances To identify appropriate abuse contact Find contact set for given object Include tech-c.email value for given object if set is empty Discard members of set unless circumstances match hint Return survivor(s) To find contact set Start with empty set Add all abuse-mailbox values found in current object While set still empty visit abuse-c, mnt-c, tech-c ... (?) Find contact set for visited object Stop visiting as soon as set is no longer empty While set still empty visit containing block Find contact set for containing block (if any) (Note: person, role, mntner have no containing block) Stop visiting as soon as set is no longer empty Return set -- Ends --