nicmx / rdap-server Goto Github PK
View Code? Open in Web Editor NEWRegistration data server application, to be plugged into a servlet container along with a data access implementation.
Home Page: https://www.reddog.mx
License: Apache License 2.0
Registration data server application, to be plugged into a servlet container along with a data access implementation.
Home Page: https://www.reddog.mx
License: Apache License 2.0
This issue is merely an observation based on the RFC 6350 section 6.4.1. It's stated that for the TEL property "Value type: By default, it is a single free-form text value (for backward compatibility with vCard 3), but it SHOULD be reset to a URI value. It is expected that the URI scheme will be "tel", as specified in [RFC3966], but other schemes MAY be used". The server uses this property for the distinct phones that a VCard could have (cellphone, voice, fax) as seen at mx.nic.rdap.server.renderer.json.VCardJsonWriter
functions getVoice(String), getCellphone(String), getFax(String).
The functions use "text" as value type, this isn't incorrect just as is mentioned in the RFC to allow backward compatibility, but the same text states that version 4.0 SHOULD use a URI value not a TEXT value. So, taking this to an example (based from RFC 7095 appendix B.1, if I have this number:
+1.1234567x890
I SHOULD expect that VCard v4.0 will display it as:
tel:+1-1234567;ext=890
When doing a search for a domain other than .MX, the query will bring zero results. This is due to an issue in which the "IN" part of the query fails to correctly include all the options for the possible zone_id's
Problem appears to be that instead of being ('80, 83'), listing should be in the ('80', '83') format.
Setup:
Answering for .mx and .lat zones
Domains---
foo223947726.lat
mydomain.mx
TLD's---
.mx = 80
.lat = 83
Queries performed--
SELECT d.* FROM rdap.domain d WHERE d.dom_ldh_name = 'foo223947726' AND d.zone_id IN ('80, 83') ORDER BY 1 LIMIT 5;
SELECT d.* FROM rdap.domain d WHERE d.dom_ldh_name = 'mydomain' AND d.zone_id IN ('80, 83') ORDER BY 1 LIMIT 5;
Steps:
Expected:
See the information regarding the .lat domain
Actual result:
404 Error
This line should probably belong to the rdap-sql-provider project.
The Data Source is specific to the SQL mechanism. When users implement their own data access, the data source is completely undesired. The rdap-server currently requires it.
As it stands, I'm forced to require the user to provide a redundant/dummy (but valid and kicking) data source as part of the custom implementation form.
Description
When inserting a domain using the insertDomainAndGet’s method located in DomainTest.java, the domain has the ccTLD concatenated. The domain name should not have contactenated the ccTLD, it should be just the name of the domain.
(Hint: this could be found un line 136)
When doing a query or search for entities its shown an error 500. Apparently this could be happening because while executing the query, it is searched for the table ipn_entity_roles which doesn´t exist.
Whenever an invalid value is placed at the properties in webapp/WEB-INF/privacy/*.properties
an IllegalArgumentException
is thrown. Eg. at the file "autnum_events.properties", set "eventAction=anyy" (note the typo) and start the server.
The issue is at mx.nic.rdap.server.util.PrivacyUtil
function loadObjectPrivacySettings(String)
. This block is at the function, I added some comments:
String property = properties.getProperty((String) key).trim();
/** Here's the problem, the exception is never handled. The enum will never have an invalid value. **/
PrivacyStatus privacyProperty = PrivacyStatus.valueOf(property.toUpperCase());
switch (privacyProperty) {
case OWNER:
break;
case AUTHENTICATED:
break;
case ANY:
break;
case NONE:
break;
default:
/** Good intentions, but the code is never reached **/
isInvalidProperties = true;
builder.append(key + "=" + property + ", ");
continue;
}
When doing a query or search of a domain, the property “variant” displays an empty bracket. The variant should display the information related with the domain.
When doing a query asking for a domain in reverse resolution it shown a message error indicating that the zone it´s not found. However, the zone is set as managed in the configuration.properties.
Apparently, there is a problem when asking for something that seems to be an IP, because the error about zone not found continues appearing. Nevertheless, when doing a query with something similar like a domain name and the zone of in-addr.arpa or ip6.arpa the response said in fact that the object is not found, but there is no problem with the zone in this case.
Asking for reverse resolution
/rdap-server/domain/0.1.168.192.in-addr.arpa
Response:
{"rdapConformance":["rdap_level_0"],"errorCode":"404","title":"Object not found","description":"Zone not found."}
Asking for a domain in the zone in-addr.arpa
/rdap-server/domain/0.in-addr.arpa
Response:
{"rdapConformance":["rdap_level_0"],"errorCode":"404","title":"Object not found","description":"Object not found."}
When defining relationship between entities and roles for a domain, There is the possibility that a domain can have several REGISTRARS binded with a domain at any given time. This type of relationship, in the context of the server, defines a type of ownership over the domain.
Nonetheless, such type of relation can't be more than one at any given time.
Expected behavior:
Only one registrar at any given time, having ownership of the domain. Past relationships with registrars should be with related with events.
Actual behavior:
Multiple relationships between a domain and a registrar entity are possible
https://www.reddog.mx/behavior-configuration.html#operational_profile
ICANN's document lists several requirements that cannot be fulfilled by RD on its own. One quick example: 1.3.8: "RDAP services MUST be available over both IPv4 and IPv6 transport."
The operational_profile
field is completely useless if its documentation fails to state what is covered by RD and what needs extra effort. We can't have users enable this switch and assume they are automatically compliant. Are we seriously expecting them to dive into the source code?
I guess what I'm asking for is a table that looks somewhat like this:
Requirement | registry | registrar | none |
---|---|---|---|
1.2 | ✓ | ✓ | x |
1.3 | x | ✓ | x |
1.4 | ✓ | Needs extra effort | x |
... | ... | ... | ... |
Also, the none
value is puzzling. Are all the "validations and requirements" disabled when none
is the active profile? Is there any reason to avoid these requirements like the plague when the user is neither a registry nor a registrar?
Hi, I'm currently implementing RDAP using your code.
The issue is: when searching domains with a valid nameserver that isn't an IDN (eg. ns1.example.com) I get a "400 - Bad Request" response; but when I search using a nameserver that is an IDN and with LDH notation, I get a valid response (eg. "200 - OK" when at least one domain is found).
The problem is at the class DomainSearchServlet
private function getPartialSearch, line
if (nsNameLabel.getLabel().equals(nsNameLabel.getULabel())) {
throw new BadRequestException("Only LDH domain labels are allowed.");
}
As said before, this logic works fine when the nameserver is an IDN and is sent in LDH notation or when the nameserver is sent with unicode chars (in this case the exception is thrown, so it´s ok).
Proposal: instead of comparing the label sent against the U-label and throw the exception when they're equal, the exception should be thrown if the A-label and the label sent aren't equal:
if (!nsNameLabel.getLabel().equals(nsNameLabel.getALabel())) {
throw new BadRequestException("Only LDH domain labels are allowed.");
}
Greetings!!
By doing a query and the information of one of the nodes can’t be displayed, it shows an empty bracket. Instead of the brackets, it should appear a notice with a description about the reason the information cannot being shown.
Not critical but still important to mantain consistency between the files:
WEB-INF
indicate the default value but in file at META-INF
don't indicate the default value.META-INF
isn't at the file in WEB-INF
.META-INF
, it isn't at file in WEB-INF
.The code is using backslashes in file names. This is the Windows way; it doesn't work anywhere else.
For the record, I found this issue in JsonUtil#createTermsOfService(String)
and HelpResult#HelpResult(ServletContext)
. This is not intended to be an exhaustive list.
The "objectClassName" attribute value should be "ip network" (https://tools.ietf.org/html/rfc7483#section-5.4), the server sends "IpNetwork" (https://github.com/NICMx/rdap-server/blob/master/src/main/java/mx/nic/rdap/server/renderer/json/IpNetworkJsonWriter.java#L36)
sample response of server:
{
"rdapConformance": [
"rdap_level_0"
],
"objectClassName": "IpNetwork",
.
.
.
}
To be honest, the installation process is a huge mess, despite the demo. There are too many steps and little to no positive reinforcement between them.
One thing that would help tremendously would be the ability to start the server with no database. If the server does not find a data source in the context, it should fall back to not respond any objects but still provide simple echoes such as an index page and the help response. Currently, it throws an exception (which is, as a matter of fact, invisible to Tomcat logs by default) and refuses to start.
As it is, I'm finding myself driven to fuse several documentation pages (1 2 3) because they are in fact one single massive atomic step, and their separation feels rather misleading and unjustified.
This case has arised in my implementation. When an entity has more than one email I can only set one email on the object VCard, so the other email is lost (at least in the response that the server will send). This is partially correct since it works, but what if I want to show both emails?
According to the RFC 6350 section 6.42 the VCard can have more than one email, so it shouldn't be a problem to place more than one email in the response. Also, if this is implemented, the emails should have the option to place the property "PREF" in case the user wants to specify the order of preference.
The reason why is_reverse_ipv4_enabled
and is_reverse_ipv6_enabled
exist is because these searches can be expensive.
But that's only assuming the SQL provider is being used with default queries. I don't think it's sensible for the server to be making assumptions regarding the data access implementation's performance.
These keys belong to the SQL provider.
Currently the server has a servlet to handle errors, this servlet is bounded to the location "/exception". This location may be used internally, but still it can be accessed externally; so when somebody access "rdap-server/exception" the server throws a NullPointerException and responds a 500 error.
I would like to make a suggestion: why not use a filter instead of a servlet? The servlet works fine, but it can give this kind of problems. Also, just in case that you decide to stay with the servlet, I suggest this: when the servlet is directly accessed it should respond with a 404 code, since that service is not part of the RDAP specs.
The property “objectClassName” located in the properties files of domain, entities and namservers was set with “none” value. But when doing a query or search, the objectClassName is still appearing in the response. This value should not be appearing in the query/search since it has a “none” value.
This is not that diffucult to work around, but it makes the installation process somewhat awkward.
If the RDAP server finds multiple implementations of the data access API, it crashes and refuses to start. This means that, in order to install a new data access implementation, the old one has to be explicitly removed.
One problem with this is that it forces the user to fake-deploy before the data access implementation can be replaced. The default implementation ships with the server WAR, so to switch the implementation I need to
Starting the servlet container before the app is configured is unnatural. This should be less traumatic:
Another drawback is that forcing one implementation per classpath forces the user to keep track of which implementations have been installed in the past. This would not be the case if only the valid one has to be referred to in a file.
When doing a search for a domain using an nsIP parameter with an ipv6, it shown an object not found, even though the object is in the bd.
This is the search that I made when asking for a domain through its nameserver ip with an ipv6
http://localhost:8080/rdap-server/domains?nsIp=1::1
This issue seems to be partially analized and fixed; right at mx.nic.rdap.server.servlet.DomainSearchServlet.getPartialSearch(String, RdapSearchRequest, DomainDAO)
there's this block:
switch (request.getParameterName()) {
case DOMAIN_NAME:
if (!RdapConfiguration.hasZoneConfigured()) {
// Is valid if there are no available zones, because the
// rdap could only respond to autnum and ip networks
// (RIR).
throw new NotImplementedException();
}
Fine, probably that's the case why the zones weren't configured, but what if they where intentionally not configured by other reasons, or they weren't configured just by mistake?
As I've understood, the server will return the 501 code when the configurator/user explicitly wants to, not by business validations (probably in some cases this is the best option). So, if the server "could only respond to autnum and ip networks" the most likely case is that the other servlets (domain(s), nameserver(s)) will be disabled at a higher level.
My proposal is that instead of returning "NotImplementedException" the function could return a "NotFoundException" (if possible, with a significative message), since the service actually could be implemented.
The same issue is at function getRegexSearch in the same class.
When doing a Domain search by nsLdhName and Regex parameters it has shown an object not found. This search should display the information of the domain requested
The object only expects 6 error codes inside its constructor, so what happens when a different code arrives as part of the parameter? For instance, when the server returns a 429 code. In this case there's no title nor description for the error.
Maybe there aren't many error codes currently returned by the server, but the "inconsistency" will grow if someone wishes to add more codes (eg. 301, 302, 303, 40x, etc.) on its own implementation. Probably the best solution will be to place a default case for the switch statement.
Beside this, I would like to suggest another thing. The codes are harcoded, wouldn't be better to declare them as constants or use something that already exists (eg. javax.servlet.http.HttpServletResponse.SC_*)?
The property “Language” is displayed in the tag of Entities and Nameservers when is made a query or search. However, language’s property doesn´t appear in the configuration’s files of entity or nameservers. Which means that the property could not be hidden. Therefore, it is suggested add a language’s property in the configuration’s files of entity and nameservers, with the purpose of hide this value when needed.
Language’s value it’s not stored in the table of Entities or Nameservers; however, when doing a query/search this value is shown in that sections. Therefore, it is suggested to review if the language’s value should be stored in Entity or Nameservers’s tables.
Assuming that the server has configured the zone "bar" at configuration.properties
, it will only allow the search of domains of such zone (nothing new). The issue appears when the zone of the searched domain isn't literally "bar". This is easier to explain with an example, if the following search is made:
/domain/foo.bar
assuming that "foo.bar" exists in my database, the response code will be 200 (OK). But if the search is:
/domain/foo.BAR
the response will be 404 (Not found), and in the body will contain the text "The zone is unmanaged by this server.".
The zones are loaded in the application just as they are written in the configuration file (mx.nic.rdap.server.RdapConfiguration.validateConfiguredZones()
), so whenever they are validated (isValidZone(String)
or even at isValidReverseAddress(String)
) the validation will succeed if it's an exact match. I would suggest that the zone can be case insensitive.
Description
In the configuration.properties file of the migrator, the parameter “migrate.users” was left empty. Therefore, this parameter should take the value “true” as default. However, is considered that the parameter took a value of “false” because when the database was cleaned, the information of the users wasn’t deleted.
Steps to reproduce:
Every search method in the API receives an integer argument called resultLimit
. This is fine, but I feel like we're deferring too much responsibility to the data access implementation.
If the implementation chooses to ignore the parameter and just build a full response for the sake of simplifying itself, the RDAP server should take care of truncating it to minimize network flood and enforce configuration policy. I mean, the DA implementation is a separate entity, and we're supposed to be liberal in what we accept from others.
This is only a suggestion so that the code organization can be improved. Currently the package mx.nic.rdap.server
has many classes of many types; this classes can be moved to other packages so that they will be placed on a more appropiated package. The reestructuration that I propose is this:
mx.nic.rdap.server.servlet.xxx
.mx.nic.rdap.server.servlet
.mx.nic.rdap.server.configuration
.mx.nic.rdap.server.listener
. This new package could be useful for somebody that could want to add its own listeners.mx.nic.rdap.server.result
.mx.nic.rdap.server.servlet
or to a new sub-package mx.nic.rdap.server.servlet.request
.mx.nic.rdap.server.servlet
.mx.nic.rdap.server.renderer
.mx.nic.rdap.server.renderer
.mx.nic.rdap.server.result
so it could be placed at that same package.mx.nic.rdap.server.notices
or mx.nic.rdap.server.xml
(honestly I prefer the first option).This a concept issue, specifically a REST concept issue. Keeping it simple, the theory is that a resource identifier can be a URL or a URN, and that "REST uses a resource identifier to identify the particular resource involved in an interaction between components" (view more); so, for this case, the URL "http://rdap.example.com/domain/foo.bar" is not the same that "http://rdap.example.com/domain/foo.bar/hello".
When both examples are resolved in the server and assuming that domain foo.bar actually exists, both will respond the same: 200 response code and the domain information. Well, this is the issue.
Currently the logic implemented is first find the servlet (eg. /domain -> DomainServlet), then get the additional path values (eg. /foo.bar/hello) to use them as parameters in the correspondent servlet. So, if there are extra parameters they are ignored (eg. DomainServlet will only use the first parameter, for the example this is "foo.bar"). Exactly at this point is where the "Resource identifier" concept is broken.
The proposal is to use the URL as it should be used, as a resource identifier, so in case that an invalid/unknown identifier is received the correspondent response will be sent (could be a response code 404, 501, 400, ...).
This souldn't affect the behavior mentioned at RFC 7480 - section 4.3.
I hope to be clear explaining this issue, if not I'm open to receive comments. Assuming that my server context is "/" and that the domain "foo.bar" exists, a request to "/domain/foo.bar" should respond with a 200 code and its correspondent body; so far nothing new. If I make a request "//domain/foo.bar" or "////domain/foo.bar" I would expect the same result, a 200 code with the correspondent body.
What's actually happening is that I get a 400 code with the description "The requested domain does not seem to include a zone.". Just to add context, the RFC 3986 URI Generic Syntax will help us. What's understood from there is that any number of "/" after the context is valid and so it should be resolved by the server; as I understood, it should be resolved as the context. Eg. "////" should be treated like "/".
So, the error code responded by the server is because the DomainServlet
is reached but is getting as a parameter the same name of the service mapped to the servlet ("domain"); in another words, is searching the domain name "domain" instead of search "foo.bar". The root of the issue seems to be at mx.nic.rdap.server.util.Util
function getRequestParams(HttpServletRequest)
, since there is where the parameter is returned so that DomainServlet
can use that parameter to make the search.
I must admit that this "issue" isn't probably that, but I would like to get your feedback. Currently the file webapp/WEB-INF/configuration.properties
states the default value for all the properties and also states that all of them are optional, eg. for the property minimum_search_pattern_length the comment is "Optional.Minimum length of the search pattern. Default 5".
It's clear that if a property isn´t uncommented, the property will have its default value loaded from resources/META-INF/configuration.properties
, but whenever the property is uncommented and without value bad things happen (someting like minimum_search_pattern_length=
. For the example mentioned before I will get a "InitializationException" with the message "The following required properties were not found or are invalid values in configuration file : [minimum_search_pattern_length]". I believe this is inconsistent with the comment for two reasons: if it's optional it shouldn't be throwing the exception when it doesn't have value, and if it has a default value, why isn't used when the property doesn't have a value?
This documentation from "behavior-configuration" seems to be incorrect:
The WEB-INF folder is the default location of the configuration.properties file, but you can define a new location by following these steps:
- In WEB-INF/web.xml, find the following lines:
<!-- <param-name> --> rdapConfigurationUserPath <!-- </param-name> --> <!-- <param-value> --> <!-- </param-value> -->
- Uncomment them, and write a valid directory path in
param-value
.- Save the changes and test the configuration.
First, because the "rdapConfigurationUserPath" is not commented, this doesn't seem to be valid XML. Secondly, I could not find this code in the predefined web.xml so there was nothing to uncomment. Third, it seems that it was envisioned that the user would be able to enter an absolute path to whatever file anywhere, but this is not working: The code never actually queries the filesystem outside of the classpath and the servlet context.
So this is currently a seemingly pointless feature; one can redefine the configuration file, but only if it still is within the context.
response-privacy largely suffers from the same problems.
I think that this was the original vision for all the configuration:
ClassLoader#getResourceAsStream(String)
) to get default values.ServletContext#getResourceAsStream(String)
), and if that fails, try and fall back to find them elsewhere (Files#newInputStream(Path)
).ServletContext#getResourceAsStream(String)
).On the other hand, from reading the code, it seems like the situation is as follows:
In other words, configuration placement is a bit of a mess right now. We need to first agree on a standard and then follow it.
https://www.reddog.mx/behavior-configuration.html#zones:
Zones managed by the server. The server will only serve domains that match this zone.
I find this field odd. Shouldn't the data access implementation be the one deciding this?
The field is especially jarring because it doesn't ship with a default value, so domain querying just plain doesn't work by default.
I feel that things should work by default. If the user doesn't want certain zones to be served, they will naturally lock them in the data access implementation. On the other hand, as it is, this field will be a natural trap for new users (who are just testing Red Dog) to fall straight into.
I think that this field should be purged. Either that or default to "manage everything".
When a partial search is made using the only wildcard allowed "*", I still can use other wildcards to get more information in the response. Here are some cases assuming that the minimum of characters allowed for the search is 5:
"/domains?name=%%a%*" will search for all the domains that have the char 'a' in their names.
"/domains?name=__e_*" will search for all the domains that the 3rd char of its name is the char 'e' followed by at least another char.
The use of this wildcards is valid when I have a MySQL or Oracle DB (just to say a few databases) as my data repository. To avoid this behavior I propose this update on the server code "mx.nic.rdap.server.RdapSearchRequest" line 80:
default:
searchReq.type = RequestSearchType.PARTIAL_SEARCH;
// Escape special characters to avoid its use as wildcards
if (searchReq.getParameterValue().contains("*")) {
searchReq.setParameterValue(searchReq.getParameterValue().replaceAll("(\\%|\\_)", "\\\\$1"));
}
break;
The purpose of the code is to escape the wildcards if the search is to be made using the sentence "LIKE" in the implementation, which I think is the most probable case.
When using the "text" renderer the content-type is supposed to be set to text/html.
However, the result is plain text. The rendering behaviour of user tools is probably undefined.
One could:
When doing a query or search asking for a nameserver it shown an Internal Error (Error 500). Apparently the problem is because it is searching the implementation of the nameserver and it didn’t find it because it's name has a typo.
This issue can be reproduced when the server uses a profile distinct than "none". The class JsonRenderer
tries to add the operational profile remark (line 60-61), and I say "tries" because after that intent the remarks are overwritten by the remarks that the result already had (line 63-64).
Precisely in the same scenario where the server has a profile, other remarks are placed before rendering the object, exactly at DomainResult
and DomainSearchResult
method validateResponse()
. Or even this could happen if another remark is added in another flow (eg. entity search).
Probably the quickest solution is: if the remark is to be added at this level (JsonRenderer
), it should be added to the list of existent remarks so that it doesn't get lost when rendering the object. The function currently used javax.json.JsonObjectBuilder.add(String name, JsonValue value)
doesn't help much right now since "If the object contains a mapping for the specified name, this method replaces the old value with the specified value". This solution could imply to modify the object received as parameter, or to add some validation at the cycle of lines 63-65, which personally I wouldn't consider the "cleanest" option.
My proposal is that this remark should be added at another level, so that the renderer do what's supposed to do: to render and not to alter the object.
The servlet "ExceptionServlet" creates an instance of "ExceptionResult" whenever its called. One of the cases in the constructor of "ExceptionResult" expects the code 500 (Internal server error); when this code is reached the error is handled as any of the others, but I believe that it should be handled in a different way.
The response for the request is ok, since the client only needs to know that an error has occurred; but internally the server should show more information about the error for the administrators to take the necessary actions on this error. It could show the stacktrace or somethig more informative than "WARNING: 500: ".
The files WEB-INF/help/1Example
and WEB-INF/terms-of-service/terms_of_service
aren't used nor referenced anywhere in the project. I'm assuming that they shouldn't exist.
When doing a query asking for a domain without a zone, the application shows an error 500. It is suggested that in this case could be shown an error 400 for malformed query or 404 for object/zone not found.
This is an example of the query that produces the error:
http://localhost:8080/rdap-server/domain/dn19
Quoting RDAP Operational Profile for gTLD Registries and Registrars:
1.5.8. The domain object in the RDAP response MUST contain entities with the following roles. Exactly one entity per role MUST be present in the response, each of them with a handle (ROID of the contact object, contact:roid, as defined in RFC5733) and valid members fn, adr, tel, email (as specified in RFC6350, the vCard Format Specification and its corresponding JSON mapping RFC7095):
- registrant
- administrative
- technical
Given that's listed among the requirements that need to be followed by both registries and registrants (and presumably also others), is there any reason why the default value of owner_roles
should not be "administrative"?
Description
It has been made a query for a domain name which has a zone that is not being managed. The error code resulting for that request was “400”. However, the error code should be “404” because the request does not contain a malformed query, it’s just that the server doesn’t have the information being requested neither the knowledge of where the information can be found. This situation only happens when doing a query. (In the case of the search the code error appears correctly)
It has been made a search/query for a domain which not belongs to mx’s zone, as a result is displayed a 404 error code. The zone was properly set in configuration.properties’ file.
Steps to reproduce:
1) Set several zones in configuration.properties’ file.
2) Make a search/query of a domain with a different zone than mx
When doing a query by IP with an object that is not in the BD it shown an Internal Error (Error 500) but instead that, it should show a 404 not found message.
When setting an element with the "authenticate" tag, such element is not retrieved when doing a search or query over a domain or element that contains such attribute.
Steps to reproduce:
Expected result:
If authenticated successfully, the query should bring every attribute marked with the "any" tag, as well as the "authenticate" tag
Actual result:
Query just brings attributes marked with "any"
Description
According to the documentation the default value of privacy is “any”. However, when those values are left empty the server fails to start. The server should not fail to start; it just has to interpret that when there is empty in whichever privacy configuration’s properties means that the value is “any”.
This situation happens with every privacy configuration property located in the privacy_default’s folder.
The remarks that are used whenever the profile is distinct than "NONE" are harcoded in mx.nic.rdap.server.util.Util
, I think that could be better to have them in a file just like the notices.
My proposal is to place this remarks (EppInformationRemark, WhoisInaccuracyComplaintFormRemark, and OperationalProfileRemark) in a file similar to notices.xml
, maybe remarks.xml
but with an additional option to indicate on which profile the remark is going to be used. This implies to create it's own schema just to differentiate them from the notices.
Beside this, currently two of the remarks (EppInformationRemark and WhoisInaccuracyComplaintFormRemark) are being loaded at the function validateResponse()
in DomainResult
and DomainSearchResult
. Just as its name indicates, the function should be used to validate, so I suggest that this remarks will be loaded in another function, something like loadRemarks()
; of course this will depends somehow of the first proposal in this issue and also could be affected by the solution (if it's going to be solutioned) of the issue #39.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.