-
-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
domain entity: handle requirement #5
Comments
Thanks for the comments! Regarding the requirement for a handle on entities, this was for a number of reasons when I was testing the library with various RDAP servers:
That limitation can be removed, however, results were "more useful" with it in place as almost all of the records that were caught by the "do you have a handle" check were junk or pointless (empty fields, results with just notes in, placeholders etc.). It's not totally accurate as per the spec as you've noticed, but it seemed to be more real world useful when attempting to actually query objects. I could make it a config flag / opt-in param as well if that would be suitable. Can you give a use case where this check might filter out a record that shouldn't be filtered out? You can always just use Feel free to submit a PR to add the |
I experienced the same, that not all rdap providers are complient to the minimal rdap_level0 and do not follow the spec. True, the parsing with I'm curently re-reading the specification and I get the conclusion, that rdap from TLD-CH does not quite follow the spec, as the registrar role contact entity does not contain a handle.
With the current code you get in the best case a registrar, tech, admin contact entity or in the worst case, nothing :) Here an example:
in this example you see thanks for the discussion. I will probably stick to parsing the raw data. |
Thanks for the example. I've just released The behaviour now is: >>> from pprint import pprint
>>> import whoisit
>>> whoisit.bootstrap(overrides=True)
True
>>> results = whoisit.domain('test.ch')
>>> pprint(results)
{'copyright_notice': '',
'description': [],
'entities': {'registrar': [{'name': 'Kreativ Media GmbH',
'type': 'entity',
'url': 'https://www.kreativmedia.ch'}]},
'expiration_date': None,
'handle': 'TEST.CH',
'last_changed_date': None,
'name': 'test.ch',
'nameservers': ['ns1.cyon.ch', 'ns2.cyon.ch'],
'parent_handle': '',
'registration_date': datetime.datetime(1996, 11, 7, 0, 0),
'rir': '',
'status': ['active'],
'terms_of_service_url': '',
'type': 'domain',
'url': '',
'whois_server': ''} I re-ran some checks and the handle check was OK to remove, it was added quite early on and other checks to remove junk results were added afterwards so it wasn't doing a great deal other than filtering non-spec compliant entities. |
thank you. just for clarification what i learned from my research:
note: CAN. not only for the
so I conclude that all gTLDs should have a well defined rdap response profile conforming to All the other TLDs, and in the most cases the ccTLDs implementations, have no requirements what they must or should return, only what properties/members are available and can be used. |
Thanks, that's generally what I'd discovered as well. The |
Hi,
saw your library today and was amazed. cool work - also for the possibility to override the bootstrap. (nic.ch is also not yet submitted in iana ;-) )
I see a problem with the requirement of a handle in the domain parsing:
whoisit/whoisit/parser.py
Line 167 in 80dc563
The rdap response profile defines this for domains:
https://www.icann.org/en/system/files/files/rdap-response-profile-15feb19-en.pdf
Section 3.2 - for registries
so entities can MAY contain a handle for the admin and technical role. (its a MUST for the registrar, but not for these two).
can we remove the enforcing of a handle in the
extract_entities
?The text was updated successfully, but these errors were encountered: