RE: [EPP-discuss] Proposal for EPP extensions in conjunction with registrant validation

From: Tom Sommer <ts_at_zitcom.dk>
Date: Wed, 12 Nov 2014 12:52:54 +0000

Also, I suggest you make contact-create ALWAYS return 1000, since the contact IS created - valid or not.
The 1001 from domain-create is about the domain not being registered yet, not about the contacts on it not being validated yet.

Thanks.
--
Tom Sommer
Zitcom A/S

Phone: +45 69 10 60 09



-----Original Message-----
From: Tom Sommer
Sent: 12. november 2014 13:51
To: 'Jonas B. Nielsen'; epp-discuss_at_liste.dk-hostmaster.dk
Subject: RE: [EPP-discuss] Proposal for EPP extensions in conjunction with registrant validation

I suggest you follow your "info contact" format. That way you keep the XML simple to read *and* parse.

So "create domain" would simply return
<extension>
                <dkhm:domain_confirmed>0</dkhm:domain_confirmed> <!-- Aktiveret -->
                <dkhm:contacts_validated>0</dkhm: contacts_validated> <!-- Alle kontakter er valideret --> </extension>

"Info domain":
<extension>
                <dkhm:domain_confirmed>0</dkhm:domain_confirmed> <!-- Aktiveret -->
                <dkhm:contacts_validated>0</dkhm: contacts_validated><!-- Alle kontakter er valideret --> </extension>

.. But in theory you could simply use the domain:status value for this?
I assume all contacts on the domain has to be valid? (hence the plural contactS) I don't *really* see a need to return this information for the domain though. Because the domain really doesn't need to say anything about the contacts it has applied. Don't know.
The most important thing are the two results/commands below:

"create contact":
<extension>
                <dkhm:contact_validated>0</dkhm:contact_validated>
</extension>

"info contact":
<extension>
                <dkhm:contact_validated>0</dkhm:contact_validated>
</extension>

Here is some inspiration: https://wiki.rrpproxy.net/Contact_Verification#EPP_server


--
Tom Sommer
Zitcom A/S

Phone: +45 69 10 60 09



-----Original Message-----
From: Jonas B. Nielsen [mailto:jonasbn_at_dk-hostmaster.dk]
Sent: 12. november 2014 13:36
To: epp-discuss_at_liste.dk-hostmaster.dk
Subject: [EPP-discuss] Proposal for EPP extensions in conjunction with registrant validation

Hello All,

At the annual registrar meeting in Copenhagen on the 5th. of November I presented the our plans to extend EPP in regard to registrant validation handling.

I have developed some more concrete examples based on the feedback I received, the suggestions was to do extensions in order to be able to communicate more precisely on the state of affairs for the involved commands:

The primary commands are "create domain" and "create contact".

I have tried to keep the extension to data bearers instead of introducing new response codes.

If validation is not applicable for the user object specified, the command will return 1000 as it is today. If validation is required the response will be 1001 and it will be extended with the following:

Create contact (1001, pending action)

<extension>
        <dkhm:pendingAction>
                <dkhm:operation>contact_validate</dkhm:operation>
                <dkhm:object_id>EXAMPLE1-DK</dkhm:object_id>
                <dkhm:exDate>2014-11-10T22:00:00.0Z</dkhm:exDate>
        </dkhm:pendingAction>
</extension>

For the create domain command we would return 1000 if a create domain request was extended with a valid order confirmation token:

<dkhm:orderconfirmationToken>XXX</dkhm:orderconfirmationToken>

Else as today a 1001 would be returned. This response would then be extended with the following:

Create domain (1001, pending action)

<extension>
        <dkhm:pendingAction>
                <dkhm:operation>domain_confirm</dkhm:operation>
                <dkhm:object:id>example.dk</dkhm:object_id>
                <dkhm:exDate>2014-11-10T22:00:00.0Z</dkhm:exDate>
        </dkhm:pendingAction>
</extension>

As for the pendingAction extension for the create contact command they contain the same information:

1. pending operation (could be named action, but since this maps to an operations list, I have decided to refer to action to keep the EPP messages consistent with the fact that an action is required and the action points to an operation).

2. object_id, the id of the object which is pending the operation (domain name or user handle)

3. date of expiration for the action

I am undecided on whether it would be interesting to communicate more pendingActions if more that one is present, since this is what we will observe as the validation requirements are implemented (and as depicted in the funnel in my presentation), validation has to take place before confirmation (this is not a business rule as such, but a safeguard to keep the user experience sane).

Create domain (1001, pending action)

<extension>
        <dkhm:pendingAction>
                <dkhm:operation>contact_validate</dkhm:operation>
                <dkhm:object_id>EXAMPLE1-DK</dkhm:object_id>
                <dkhm:exDate>2014-11-10T22:00:00.0Z</dkhm:exDate>
        </dkhm:pendingAction>
        <dkhm:pendingAction>
                <dkhm:operation>domain_confirm</dkhm:operation>
                <dkhm:object:id>example.dk</dkhm:object_id>
                <dkhm:exDate>2014-11-10T22:00:00.0Z</dkhm:exDate>
        </dkhm:pendingAction>
</extension>

Please note that the pending actions would be in no specific order, since the order not dictated currently, as mentioned above and this might change in the future. But I want to avoid over-engineering and feature creep. If order, precedence or priority becomes important it could be communicated as part of this information.

If the all pending actions are communicated as part of the response for create domain, it could an idea to extend the XML.

<extension>
        <dkhm:pendingActions>
                <dkhm:pendingAction>
                        <dkhm:operation>contact_validate</dkhm:operation>
                        <dkhm:object_id>EXAMPLE1-DK</dkhm:object_id>
                        <dkhm:exDate>2014-11-10T22:00:00.0Z</dkhm:exDate>
                </dkhm:pendingAction>
                <dkhm:pendingAction>
                        <dkhm:operation>domain_confirm</dkhm:operation>
                        <dkhm:object:id>example.dk</dkhm:object_id>
                        <dkhm:exDate>2014-11-10T22:00:00.0Z</dkhm:exDate>
                </dkhm:pendingAction>
        </dkhm:pendingActions>
</extension>

I do not think the extra tag is necessary or required, so it would be a matter of taste - correct me if I am wrong.

In order to be able inspect contact object prior to create domain, we plan to extend the info contact with a validation status as follows:

Info Contact (1000)

<extension>
        <dkhm:contact_validation>validated</dkhm:contact_validation>
</extension>

The possible values would be:

- unvalidated
- validated
- not applicable

We are also evaluating the possibility of communicating possible pending actions as described above in the domain info command.

Looking forward to receiving your feedback on the above proposal.

jonasbn
--
Med venlig hilsen/Best Regards
Jonas B. Nielsen
Software udvikler/Softwaredeveloper


Kalvebod Brygge 45, 3. sal
1560 København V

Tlf. +45 33 64 60 60
Mobil: +45 31 54 60 56
Fax.: +45 33 64 60 66
Email: jonasbn_at_dk-hostmaster.dk
Homepage: https://www.dk-hostmaster.dk

.dk Danmarks plads på Internettet

-------------------------------------------------------------------------
Dette er en e-mail fra DK Hostmaster A/S. Denne e-mail kan indeholde fortrolig information, som kun er til brug for den tiltænkte modtager.
Hvis du ved en fejl har modtaget denne e-mail, bedes du venligst straks give afsenderen besked om dette og slette e-mailen fra dit system uden at offentliggøre, videresende eller tage kopi af meddelelsen.

This is an email from DK Hostmaster A/S. This message may contain confidential information and is intended solely for the use of the intended addressee. If you are not the intended addressee please notify the sender immediately and delete this e-mail from your system. You are not permitted to disclose, distribute or copy the information in this e-mail.
--------------------------------------------------------------------------


Received on Wed Nov 12 2014 - 13:52:54 CET

This archive was generated by hypermail 2.3.0 : Fri Feb 06 2015 - 11:39:29 CET