how to proceed with changed:

Daniel Karrenberg wrote:
> 
> Let my try to summarise the discussion:
> 
> 1) changed has a fuzzy definition, a more concise audit trail attribute 
>    should replace it. A concrete proposal is needed. David has already 
>    thought about this. Want to write it up. Do *not* call it changed:!
> 
> 2) I porposed to exclude changed: from answers to normal queries.
>    Present the changed attribute only when the query contains a special 
>    flag (like -c).
> 
>    The only serious problem with the proposal I have read so far is the
>    comparison for deleting an object. This could be changed to exclude 
>    changed: attributes. 

Why not just use NIC/RIPE-handles in the changed field?  As long as the
server didn't automatically return the corresponding person object when
queried (unlike the admin-c, tech-c, etc fields unless the "-r" flag is
given) this would hide email addresses from the casual database user while
still providing more information for those who "need to know".

Regarding the date in the changed field, doesn't the database software check
that a new object doesn't have a changed date older than the existing
database entry?  If not, isn't this something it should do?  In any case,
having the date (and time?) in the changed field in a standard format (ISO
8601:1988, perhaps) would, IMHO, be useful although it should probably be
added by the database software rather than by the user submitting the
update.

Just my thoughts.....

James

--
                "You are not expected to understand this."
                                Ken Thompson, Unix V6 kernel source.