Hi Roger,
Thanks for taking the time to answer my question.
I try to convince myself using client validation / UX argumentation. The most
common user journey we experience – but maybe that’s not a typical user journey
for all TLDs? – is:
1. A candidate Registrant visits the Registrar website
2. The candidate Registrant checks one or more domains
3. The candidate Registrant repeats step 1 and 2 on 1 or more other
Registrar websites (this is typically what we see in the logs).
4. He selects a Registrar (most of the time, cost is the deciding factor)
5. The candidate Registrant “adds the domain to his cart” on the website of
the selected Registrar
6. He fills in his contact details (Registrant details)
7. The candidate Registrant “buys” the domain (incl. some web hosting)
I understand that the current situation is really bad for Registrars: in step 6
the Registrant fills in his details, everything looks OK, but after selecting
his web hosting etc. he clicks they “buy” button, but it seems his “contact
details” are not valid.
I just don’t see yet why transactions would not be another valid approach to
this problem. At step 6, the Registrar could perform the following actions:
1. Start transactions. Mode = auto-rollback
2. Create contact within transaction (transaction ID as extension)
3. Create domain within transaction (transaction ID as extension).
Registrant id = contact id of previous command
4. Stop transaction. Create contact and Create domain are not persisted as
transaction is auto-rollback.
(Step 1 and 2 and step 3 and 4 could be combined by allowing “start/stop
transaction” as an extension of any command. But that’s just optimization.
Principles are best explained by describing all steps.)
2 to 4 steps seem a lot for a client just to validate a contact, especially in
terms of RTT, but:
1. It all depends on implementation. Using an asynchronous implementation,
the negative effect of 2 commands is negligible.
2. As far as UX is concerned, the final delay is hardly noticed by the
Registrant.
But far more important than this possible disadvantage are the advantages:
1. It’s a simple concept. Everybody knows transactions, rollback, etc.
2. I can imagine as a former developer that implementation is very
straightforward for Registries with a transactional database as backend
3. The use of object extensions is straightforward: just apply them as you
would do otherwise. No key/value concept needed.
4. Last but not least, it has a huge range of possibilities. Example
situations which can be covered by transactions:
* A Registrant wants to either register 2 domains or none if one of the
2 domains can’t be registered for some reason.
* Various Registry policies can be detected early:
i.
Registrants can only register domains using the code points only known to their
country code
ii. A
Registrant from a foreign country (ccTLDs) can only register domains for 1 year
iii. More
general: a Registrant with extension X=Y is only allowed to register a domain
if the domain extension A=B
* It could even be extended to other commands, e.g. testing transfer
requests / domain deletes / … without actually executing them
* …
Not convinced? No hard feelings of course 😊
Kind regards
Pieter
--
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be<http://www.dnsbelgium.be>
[DNS_PUNT_Belgium_RGB]
From: regext <[email protected]> on behalf of Roger D Carney
<[email protected]>
Date: Tuesday 17 July 2018 at 18:36
To: Registration Protocols Extensions <[email protected]>
Subject: Re: [regext] REGEXT Interim Meeting (2018JUN05) Notes
Good Morning,
Thanks Pieter. I think the real goal of Validate is improved customer
experience.
I don’t think wrapping this in a transaction helps as the error identification
is still occurring to late in the process.
There are quite a few steps in the registration process but today one of the
main issues comes at domain create time (this is basically the last step in the
process along with collecting fees).
Today, validating contacts in terms of their “roles”/contactType
(Registrant/Admin/Tech/etc) occurs at Domain Create time, which is way too late
for a good customer experience. A contact maybe a valid contact for the
Registry but it may not be a valid contact for the “role” /contactType. So what
we want to do is validate this data in as full of context as we can before the
Domain Create / Collection of fees. Getting an error at this point (domain
create) causes a painful customer experience and a lot of additional processing
to occur.
Thanks
Roger
From: regext [mailto:[email protected]] On Behalf Of Pieter Vandepitte
Sent: Friday, July 06, 2018 7:05 AM
To: Registration Protocols Extensions <[email protected]<mailto:[email protected]>>
Subject: Re: [regext] REGEXT Interim Meeting (2018JUN05) Notes
Short question regarding the validate extension:
Isn’t the purpose of the validate extension to do what actually transactions
are meant for? Ultimately the goal of the validate extension is to check
whether a group of commands are possible: create some contacts, link the
contacts to a domain with a specific role.
Why not trying to add a layer on top of EPP to enable transactions? Start a
transaction, add commands to a transaction, execute a transaction with either
commit or auto roll back?
I think that would lead to a much simpler model and could easily deal with
other objects and other extensions.
Thoughts?
Pieter
--
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be<http://www.dnsbelgium.be>
[DNS_PUNT_Belgium_RGB]
From: regext <[email protected]<mailto:[email protected]>> on
behalf of Roger D Carney <[email protected]<mailto:[email protected]>>
Date: Tuesday 3 July 2018 at 20:04
To: Registration Protocols Extensions <[email protected]<mailto:[email protected]>>
Subject: [regext] REGEXT Interim Meeting (2018JUN05) Notes
Sorry about the tardiness, please enjoy, see everyone in a couple weeks.
Meeting started at 11:06 (UTC-5)
Attendees: Roger Carney, James Gould, Jody Kolker, Jim Galvin
Agenda
1. Validate draft (comments, concerns, implementations)
2. Registry Mapping
a. Continue the lively discussion that was started in London
b. Policy Extension Review: how a server implements an extension, the
SHOULD(s), MAY(s), etc.
Jim Galvin mentioned that co-chairs have been discussing milestones and updated
charter with AD (Adam). Hopefully circulate new Charter to the group next week.
Planning two meetings for IETF-102.
James Gould said that he has started implementing the Validate draft in their
SDK. I mentioned that Nominet has already implemented.
We started out discussing the Validate draft, specifically the questions James
Gould posted to the list Monday June 4, 2018, copied below:
1. I don’t see the purpose of the <validate:cd> element in the check
command.. Initially, I thought the <validate:cd> may support a list within a
list (e.g., <validate:contact>), but that is not the case. There is also a
little confusion with the use of <validate:cd> in both the check command and
response. My recommendation is to remove the <validate:cd> element from the
check command and simply move all its sub-elements to sub-elements of the
<validate:contact> element. [Interim] Interesting for removal, post to list.
2. Is the extension meant to validate the contact details of existing
contacts by contact id and also non-existent contacts based on the contact
details, by contact type and by tld? [Interim] Yes, both scenarios. For “new”
contacts pass all data, don’t try to short cut it with only id, if only id is
passed server will assume it is an existing contact. Change response
validate:cd to include TLD and contact type attributes. Discussed the
preferences of smaller payload versus complicated payload, went with simpler.
Add a new section to 2.0 describing validate:id (Need to have response pass
back contact type and tld).
a. If both cases are true, then wouldn’t you have a choice of referencing
the contact by identifier for an existing contact or defining the contact
attributes for a non-existing contact?
b. Also, what if you desire to use the same contact information for multiple
contact types for a tld?
1. Do you need to replicate the same attributes for each contact type?
[Interim] Simple method would
2. It may be better to define a single contact (existing with contact
identifier) or contact attributes for non-existing with the list of contact
types. I imagine that you always want to validate a contact within the scope
of a tld. [Interim] Interesting, thoughts?
3. I view definition of only the check command and response with many
contacts and with extensibility via the kv elements as somewhat non-optimal.
Other options include:
a. Instead of supporting multiple contacts in an individual command, why not
support the check or info of an individual contact with attribute extensibility
via command / response extensions. Yes, you can validate only a single contact
with multiple target types and a tld at a time, but you get to use existing
contact command / response extensions to define the additional contact
attributes without having to use key / value pairs. [Interim] One goal is to
pass in multiple contacts and validate as a whole
b. Create a validate command / response extension of the contact mapping
that extends the contact create to function as a no-op with the additional
attributes used to validate usage of the contact (e.g., object - domain,
contact types, tld), which would define a validate contact validate create
command. The contact info could have been extended by the validate extension
to function as a validate usage command with the usage attributes consistent
with the contact validate create command (e.g., object – domain, contact types,
tld). In this case, the contact commands can be directly extended by the
validate extension. [Interim] So does key/value make sense here. Can this
validate extension be able to be extended with other extensions (e..g. registry
has a VAT extension instead of this)?
4. Each element needs to be fully described.. I include some examples below:
a. <validate:contact> element does not define the required “contactType” or
“tld” attributes. [Interim] Add more descriptions
b. There is no description of any of the <validate:cd> sub-elements in the
check command or response. [Interim] Add more descriptions
5. Wouldn’t be better to include a required “valid” attribute in the check
response <validate:cd> element with an optional reason and reason language
similar to the domain check response? I’m not sure if there is a real need to
define a whole list of validity errors using the list of <validate:kv>
elements. It may be good enough to short circuit the validation by simply
saying yes or no and if no a human readable reason. There would be no need for
the <validate:response> element or the <validate:kv> elements. [Interim]
Should the response look more like a check response (result, and free form text
response if invalid)? I like the draft format better but I understand the
consistency part
6. I don’t recommend directly referencing the
urn:ietf:params:xml:ns:contact-1.0 elements, since it adds a direct dependency
to inclusion of the contact XML schema and namespace for a subset of the
elements that are really specific to the validate mapping. I would prefer for
the validate XML schema to stand on its own by only referring to epp and
eppcom, with no cross references to contact. This would mean copying and
pasting elements directly from the contact XML schema into the validate XML
schema, which is an inconvenient, but makes it easier to implement. [Interim]
There has been discussion on list on this topic, continued discussion will be
good.
We did not make it to the Registry Mapping discussions.
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
