23 Srp
2016
23 Srp
'16
23:10
On 23/08/16 19:26, Jaromir Talir wrote:
I believe this can make a fair usage in case of a registrar. E.g. you create an invoice
with address
A, print it and mail to address B. However, I'm not convinced that this makes sense in
case of a
registry which sends nothing at all and the only address is supposed to be "the legal
address". I
understand your situation and efforts with MojeId, I'm only wondering if other
registries will
utilise that. (Although 1 is still a valid case of having N choices.)
When it comes to changes addresses it might be nice for some to make the street not
obligatory
field, because there are countries in which the street address can be missing and it's
perfectly
fine. ;-)
So my guess that this is for contact/address validation was right. ;-)
I'm not aware of the law you must obey/implement in your system.
This seems to be like a policy forcing every contact to be nice and valid for all domains,
even if
they're not causing any trouble (like having sites which might be illegal in any part)
and BEFORE
they cause trouble.
Are you forced to do that? Maybe you're not allowed to assume that each
registrant/admin is honest
and peaceful "until proven guilty", or even "accused"?
Oh yes, this makes a perfect sense.
Thank you for your answers.
Best regards
Piotr
On Tue, 2016-08-23 at 16:23 +0200, Piotr Przybył
wrote:
What I had in mind precisely was that the page lists e.g.
https://fred.nic.cz/files/fred/sources/fred-db-2.21.6.tar.gz, which doesn't contain
notification_queue for instance. I discovered the SQL upgrade script installed by the
package, but
can't see it in sources tarball.
Hello cz.nic Team
I have a few questions related to database migration of FRED if you
don't mind.
====
When trying to download the latest sources from https://fred.nic.cz/p
age/2904/download/#source I've
realised, that they're not available. E.g. the latest migration
scripts are available in
fred-db*deb, but the tarball is not a corresponding one.
Could you please try to release latest sources in tarballs?
The last version I've uploaded on the website is 2.23. We have released
small upgrades 2.24 and 2.25 but there is an issue with building them
on Fedora 24 so I'v postponed next website update to 2.26 that will be
available for recent Fedora system. I believe this will be available
next week and I'll do website update immediately after that. ====
Could you briefly describe what's the purpose of tables:
contact_address
contact_address_history
As far I can tell after analysing the sources, these tables are
populated by a functionality called
from MojeID ( =your special NIC registrar to keep domain contacts
defined at central level, not each
registrar's level).
There is a concept of single address in FRED. In our mojeID registrar
we have a concept of multiple addresses (mail address, permanent
address,...). We decided to move this concept down into FRED and
implemented multiple addresses in FRED database. The next step was
supposed to be propagate this multiple address manipulation into EPP
but this was postponed for a while. I believe we will get to his soon. ====
What are the following tables for? Or: How the checks of contacts are
working? Is is something
related to checking if a contact's address fields are valid?
contact_check
contact_check_history
contact_check_message_map
contact_check_object_state_request_map
contact_check_poll_message_map
contact_test_result
contact_test_result_history
contact_testsuite_map
enum_contact_check_status
enum_contact_check_status_localization
enum_contact_test
enum_contact_test_localization
enum_contact_test_status
enum_contact_test_status_localization
enum_contact_testsuite
enum_contact_testsuite_localization
That would be loooong explanation :) I believe this will be part of new
documentation that Lena is working on. I talked about this briefly
during ICANN Techday
https://fred.nic.cz/files/fred/FRED-Validation.pdf slide 12,13
(selective contact validation). ====
There's a table notification_queue. I can't find any usage of it
(maybe because not all tarballs are
up to date). What is it for?
I was going to mention this in mail summarizing changes in FRED-2.24,
2.25 and 2.26. There is a new concept of asynchronous notification in
FRED-2.25. In previous versions when registrar issued EPP command that
involved sending notification email to registrant, EPP command was
waiting for notification subsystem to create this email. Asynchronous
notification means that there is only small record in
notification_queue table that notification should be send and
asynchronous script will create this email in separate process. The
advantage is greater speed of EPP and stability because when subsystem
for notification email creation is not available EPP is not locked. Do you replicate this table using Slony? (Because
it has neither
primary nor unique key.)
We are not using Slony anymore, we have changed to internal streaming
replication about 4 years ago. Maybe that's why we missed to add
primary key. I'll ask my colleagues to add this primary key.