False positive on media types

[anewton1998]

When running the tool against Aliyun, I am getting false positives for links with media types of "text/html" and "application/rdap+json".

java -jar tool/target/rdapct-1.0.4.jar -c tool/bin/rdapct-config.json -v --use-rdap-profile-february-2019 --gtld-registrar https://whois.aliyun.com/rdap/domain/haidiya.com

[jmoreira-ls]

Having locally built the tool (using the master branch and compiled with mvn -DskipTests package), I'm having the same issue. I also went through the download media types dataset and both text/html and application/rdap+json are present.

[anewton1998]

I'm also seeing this against other registries.

[gbrodman]

For what it's worth, we're also seeing this as well -- it looks like the MediaTypes dataset is using the "name" attribute of each media type, pulling from the dataset located at https://www.iana.org/assignments/media-types/media-types.xml. For a standard HTML mime type, it looks like that "name" value is "html" instead of the valid MIME type "text/html"

[anewton1998]

These false positives may be ignored using the config file in the v1.0.6 release .

[gbrodman]

These false positives may be ignored using the config file in the v1.0.6 release .

I don't think this is entirely the case, or to be more specific, I don't think it includes all error codes. I'm receiving the error code -12309, or to be more thorough:

"error": [{
    "code": -12309,
    "notes": "",
    "message": "The value for the JSON name value does not pass #/entities/1/remarks/0/links/0/type validation [stdRdapRemarksValidation].",
    "value": "#/entities/1/remarks/0/links/0/type:text/html"
}]

even with the new configuration, which makes sense because -12309 isn't ignored.

[anewton1998]

Thanks. We'll try to add this to this list.

[bchen-godaddy]

Hello, our team encountered the same issue of error code -12309 when we check our RDAP response using this tool.

It turns out there is a potential bug in MediaTypes, the class is responsible for loading all media types from a XML file. However,

• It did not load all types in current implementation (due to incorrect XML mapping).
• Besides, it did not get the correct media type string (e.g. should be video/3gpp but it only loads 3gpp).

That's why most of the time it complains about "value": "#/entities/1/remarks/0/links/0/type:text/html"

I pushed a PR #62 just now, in attempt to fix it - hopefully it would help this issue?