26 Srp
2016
26 Srp
'16
17:31
On Tue, 2016-08-23 at 23:10 +0200, Piotr Przybył 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. ;-)
Actually there is a meaning for registry. We send snail mail letter
with information about expiration some time before actual deleting
expired domain. Those letters are generated in PDF form regularly in
FRED. Those letters are now sent to "mailing" address and not "legal"
address if those two addresses differs.
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"?
I guess that everybody want's to have correct data in system.
Incorrectness cause us troubles when we want to reach registrants. We
have registration rules where we say that contact data inserted into
registry should be correct. So while we cannot easily enforce
correctness on input, we decided to check validity of data that we
already have in registry.
Jaromir
Oh yes, this
makes a perfect sense.
Thank you for your answers.
Best regards
Piotr
_______________________________________________
fred-users mailing list
fred-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/fred-users --
Jaromir Talir
Technicky partner / Technical Fellow
-------------------------------------------
CZ.NIC, z.s.p.o. -- .cz domain registry
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:jaromir.talir@nic.cz http://nic.cz/
sip:jaromir.talir@nic.cz tel:+420.222745107
mob:+420.739632712 fax:+420.222745112
-------------------------------------------
On 23/08/16 19:26, Jaromir Talir wrote:
Yes, you are right. The reason is that deb packages in archive are
always newer than those published on the website. I believe this will
be in sync at the end of next week.
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.