[db-wg] Recent Database update changes

[ Apologies for duplicate messages ]

Dear Colleagues,

In preparation of a new release of the Whois software we have fixed several 
bugs and implemented some of the simple features asked for over the last few 
months for the update program, dbupdate. A brief description follows of the 
features implemented.


1) Change to the overall result of a mail update message.

During the re-structuring of the dbupdate program we changed the way we report 
the overall result of a mail update. This caused some confusion and we have now 
returned to the behaviour of the previous version of dbupdate. To make this 
clear here are the outcomes we now report:

A blank update message - FAILED:
ANY object update failed - FAILED:
Otherwise - SUCCESS:


2) Handling of keywords in the Subject: line of a mail update.

Currently there are only two keywords used by dbupdate. These are NEW and HELP 
(HOWTO is also valid but taken to mean the same as HELP). NEW forces all 
objects found in the mail message to be treated as a creation request. Any 
object that already exists will result in an error. HELP returns help text.

To use a keyword it has to be put in the Subject: line of the mail message, 
with NO other words present. If any other word is found for example

Subject: NEW objects

then none of the words are actioned as keywords and they are all reported in 
the acknowledgement reply as invalid keywords. In this context it is impossible 
for dbupdate to know if a word is a keyword. As many users often include their 
own reference in the Subject: line it means it is impossible for them to also 
use a keyword and they always get their references reported in the Warning 
messages af the acknowledgement.

To overcome these problems we have introduced a KEYWORDS: tag. When this tag is 
found in a Subject: line all text up to and including this KEYWORDS: tag is 
ignored by dbupdate. Only what follows this tag is checked for valid keywords. 
The same rules apply as before. If a word is found after the KEYWORDS: tag that 
is not a valid keyword none of the words are actioned as keywords. In this case 
all the words following the KEYWORDS: tag are reported as invalid keywords in 
the acknowledgement reply.

Adding the KEYWORDS: tag at the end of a Subject: line means that valid 
keywords can still be used with a users reference in the same line. By adding 
the KEYWORDS: tag at the end of the Subject: line with no keywords following it 
means that the users reference will not be reported as invalid keywords. The 
default behaviour is unaltered. A keyword can still be placed on a line with no 
other words and actioned.

We could easily make another change, if users would prefer it, so that keywords 
will ONLY be accepted if they follow the KEYWORDS: tag. This would make the 
default behaviour ignore the whole Subject: line and not report any of it as 
errors if the KEYWORDS: tag is not found. This default behaviour may be more 
appropriate to the way the Subject: line is currently used in most cases. 
Please let us know if this is preferred.

All keywords and the KEYWORDS: tag are case insensitive.


3) Differnce in notification messages

We have been asked to highlight changes in the notification message between the 
old and new objects for a modification operation. This is particularly useful 
when "import:" and "export:" attributes are changed in large AUT-NUM objects.

This has now been implemented as a selectable option. To request it the user 
includes the keyword DIFF. When this DIFF keyword is used each object in the 
notification message that is a modify operation will include a difference 
before the standard output of the old and new versions of the objects. So the 
output will have the difference listing followed by the old and new objects.

For example, a new subject line may look like this

Subject: changes to aut-num: as1234  KEYWORDS: DIFF

The difference is the standard unix diff, but with one slight change. In our 
acknowledgement and notification messages we have used three dashes --- 
followed by a new line to signify the start of a section relating to an object. 
This is to make it easy to parse the output and find the start of each object 
in the message. Unfortunately diff also uses --- to seperate lines that have 
changed. So we have had to replace --- with === in the diff output.

If the DIFF keyword is not used the output remains unchanged. Using a simple 
PERSON object as the example the new output is as follows:

---
OBJECT BELOW MODIFIED:

Differences in [person] TP10-DB-TEST

7c7,8
< notify:       case040-1 at ripe.net
===
 > changed:      dbtest at ripe.net 20040101
 > notify:       case040-2 at ripe.net


person:       Test Person
address:      Singel 258
address:      Amsterdam
phone:        +31 20 535 4444
nic-hdl:      TP10-DB-TEST
changed:      dbtest at ripe.net 20020101
notify:       case040-1 at ripe.net
source:       DB-TEST


REPLACED BY:

person:       Test Person
address:      Singel 258
address:      Amsterdam
phone:        +31 20 535 4444
nic-hdl:      TP10-DB-TEST
changed:      dbtest at ripe.net 20020101
changed:      dbtest at ripe.net 20040101
notify:       case040-2 at ripe.net
source:       DB-TEST


4) Include person/role name in creation results.

The last additional feature is to include the name of a PERSON or ROLE object 
in the acknowledgement output after a successful creation. Previously only the 
new nic-hdl was listed. For example, if two PERSON objects are created using 
AUTO- nic-hdls for Denis Walker and David Wilkinson the reply would only say 
DW23-RIPE and DW24-RIPE have been created. The user would then have to do a 
whois lookup to determine which was which. The reply now states:

---
Create SUCCEEDED: [person] DW23-DB-TEST       Denis Walker


---
Create SUCCEEDED: [person] DW24-DB-TEST       David Wilkinson


Regards
Denis Walker

RIPE NCC Software Engineering Department.