[Reddog-public] RDAP Extensions

Paco Moreno pc.moreno2099 at gmail.com
Thu Mar 8 18:27:42 CST 2018


Hi Dominic.

In order to add custom fields or support extensions there are several
things to do, since currently RedDog doesn't have a simple way to do such
things (definitely this should be easier to do, this will be added on a
future release). You're right, the renderer exists specifically for support
different output formats; if any content is going to be added, this should
be done also at the objects in another level.

So, these are the things that could be done to achieve what you're looking
for:

[MAIN UPDATES]

Project "rdap-server"
+ Add the extension to the RDAP conformance list, just as stated in RFC
7483 section 4.1. This can be added to the "RdapResponse" object; let's
take "mx.nic.rdap.server.result.DomainResult" as an example, the extension
can be added at following lines in the constructor:

domainResponse.setRdapConformance(new ArrayList<>());
domainResponse.getRdapConformance().add("rdap_level_0");
domainResponse.getRdapConformance().add("my_extension"); // Custom
extension added

Project "rdap-core"
+ Depending on the objects altered by the extension, the new properties
could be added to the core, either to an existing object or stated at a new
object. Note that all objects extend "mx.nic.rdap.core.db.RdapObject".

Project "rdap-sql-provider" (only if you're using this reference
implementation)
+ Depending on how the data is loaded from the DB, the queries at
"src/main/resources/META-INF/sql" should be updated to load such data. The
new columns must be mapped just as stated in the next point.
+ The properties mapped to the corresponding DB fields should be loaded in
the affected classes at "mx.nic.rdap.sql.objects" package.
+ Probably the classes at "mx.nic.rdap.sql.model" package won't be
modified, but if there's something that must be done different when
querying the DB, then the corresponding classes must be updated.

Project "rdap-json-renderer" (only if you're using this reference
implementation)
+ Depending on which object the new data is displayed, the changes must be
made at the corresponding renderer. The class
"mx.nic.rdap.renderer.json.JsonRenderer" is the implementation used to
render the information, the properties could be added here or to a lower
level, at the classes of "mx.nic.rdap.renderer.json.writer" package. Take a
look on this classes to learn how they show the data.

[PRIVACY UPDATES]
If there are properties related to the extension that need privacy
settings, these are the steps to follow:

Project "rdap-server"
+ Update the default privacy settings directory
(src/main/resources/META-INF/privacy_default) by adding the new properties
to the existing files, or by adding a new file containing the corresponding
properties keys. Additionally, the privacy configuration directory must
mirror those changes and can be configured just as stated in the
documentation https://www.reddog.mx/response-privacy.html.
+ The privacy settings are loaded at "mx.nic.rdap.server.util.PrivacyUtil",
so all the changes made at the privacy settings files must be loaded at
this class. Note that if new properties were added to the existing files,
there's no need to make changes at this class; but if there were new files
added to the privacy settings directory, then such files must be added to
be loaded. Take the "Domain" object as an example to know what must be done:

public static final String DOMAIN = "domain"; // Add the key
public static void loadAllPrivacySettings() throws IOException {
/* ... */
loadObjectPrivacySettings(DOMAIN); // Load its content
/* ... */
}
public static Map<String, PrivacySetting> getDomainPrivacySettings() {
return OBJECTS_PRIVACY_SETTING.get(DOMAIN); // Create its getter
}

+ Take a look at the "*Filter" classes in the "mx.nic.rdap.server.privacy"
package (e.g. "AutnumPrivacyFilter", "DomainPrivacyFilter"). The properties
related to the extension could be added to an existing filter, or they
could have their own filter, whichever suits your needs. If new properties
were added, its keys must be added as well; if a whole new file was added,
then its corresponding filter could be added. Again, take as an example
"Domain", in this case the "DomainPrivacyFilter" class; look how the
"PrivacyUtil.getDomain*PrivacySettings()" function is called to iterate
over the keys returned and apply the corresponding privacy setting.


Basically that's it, and if we're missing something or there's doubt, don't
hesitate to let us know that. We admit that probably isn't an easy task to
add a custom extension or properties, but this kind of things will help us
to improve this RDAP implementation.

Best regards, RedDog's development team


El jue., 8 de mar. de 2018 a la(s) 09:55, Dominic Ast <dominic.ast at switch.ch>
escribió:

> Hi there
>
> I am looking at the RegDog RDAP implementation respectively it's
> documentation. Is there a way to add custom fields for example to a
> domain which is allowed by RFC7483 (prefixed)  or to support a RDAP
> extension? I didnt see that stuff in the documentation as I think that
> the renderer is just for supporting different output formats and not for
> adding content? Thank you for any hint.
>
> Best regards, Dominic
>
>
> _______________________________________________
> Reddog-public mailing list
> Reddog-public at nic.mx
> https://mail-lists.nic.mx/listas/listinfo/reddog-public
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail-lists.nic.mx/pipermail/reddog-public/attachments/20180309/201b7337/attachment.html>


More information about the Reddog-public mailing list