Hi Denis,
Unfortunately it is not easy to accommodate every possible arrangement and keep it tightly controlled.
Agreed. I think we have a different opinion on where to put the cursor between control and flexibility. Most of the time I'd grant more liberty, simply because it make the life of well behaving people easier. And the others will find workarounds, no matter what the corols are.
Before "abuse-c:" was introduced the "abuse-mailbox:" attribute was allowed in 5 object types and it became unmanageable. (It still is in 5 object types as the clean-up has not yet been done.)
Yes, and I think the inheritance part of the abuse-c is a big step forward. But even the abuse-mailbox could have worked if there was a clear query path, so that the producer of the information knew what request produced what result.
BUT, I have a real issue with the workaround. The argument for restricting the abuse-c to an organisation was to prevent duplicate data, especially the hypothetical appearance of unmaintained contacts. However, this is exactly what you are proposing with a duplicate ORG. So
Strictly speaking it is not exactly a 'duplicate' ORGANISATION object.
Strictly speaking, you are right. For all practical purposes, you are not :)
Something is different at this point in your network (abuse handler).
Correct. It is a difference in the network (or management of a certain part), not in the organisation. As I said, I can live with the current restriction, even if it frustrates me. It is the consumers of abuse-c that should be annoyed.
I really wish people were willing to at least talk about a data model review.
Why not? best, Gilles -- Fondation RESTENA - DNS-LU 2, avenue de l'université LU-4365 Esch-sur-Alzette