Hi, an other good idea Job. The changed lines do not show any valuable information as long as the date can be manually altered. Additionally, your first query did not return any changed lines as these include an e-mail address and are therefore not returned unless you use the -B flag. The changed history can provide information only to the one who maintains the object, as adding or removing changed lines is usualy done according to each company's internal processes/procedures. For example, the best practice is to add a changed line every time you edit an object. I've rarely seen someone following this practice every time they update a RIPE Database object. Plus, adding 100s of lines to an object does not help anyone. Therefore, a +1 from me. cheers, elvis On 15/04/14 15:31, Job Snijders wrote:
Dear DB Working Group,
Assessing the "freshness" of database objects can be a useful component in many business processes, but as it stands today the "changed:" attribute is severely crippled:
Eleanor:~ job$ whois -h whois.ripe.net AS15562 | grep changed Eleanor:~ job$ whois -h whois.radb.net AS15562 | grep changed changed: unread@ripe.net 20000101 Eleanor:~ job$
Fantastic! Now we are absolutely none the wiser. :-)
I propose that we introduce a new attribute called "last-modified" as a replacement for functionality offered by past implementations of "changed:".
The "last-modified" attribute is set by the whois server software and represents the date and time at which the last succesful modification was received by the server. When a user submits an update for an object in which the attribute is present, the server software will ignore the attribute, insert its own attribute with the current time, and present a warning to the user that the user's version of "last-modified" was ignored. The "last-modified" attribute should be presented by the server software in all types of objects (autnums, poems, etc) for which the server is responsible (e.g. do not touch foreign or mirrored objects).
The date and time are represented following the ISO 8601 [1] profile for complete date plus hours, minutes and seconds, always expressed in UTC, including the special UTC designator 'Z'. The "last-modified" attribute should be presented above, but close to the "source:" attribute.
The advantage is that the date and time are both human readable and computer parsable!
A valid example "last-modified" attribute would be:
last-modified: 2014-04-15T13:15:30Z
I look forward to the group's feedback! Also, I'm interested in how people would use this attribute in their workflows or automation.
Kind regards,
Job
[1] - https://xkcd.com/1179/