Roger,
I preparation for the Interim Meeting, I did a deeper dive into the Validate
draft, and I have the following feedback:
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.
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?
* 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?
* Also, what if you desire to use the same contact information for
multiple contact types for a tld?
i. Do you
need to replicate the same attributes for each contact type?
ii. 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.
1. 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:
* 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.
* 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.
2. Each element needs to be fully described. I include some examples below:
* <validate:contact> element does not define the required “contactType”
or “tld” attributes.
* There is no description of any of the <validate:cd> sub-elements in
the check command or response.
3. 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.
4. 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.
—
JG
[cid:image001.png@01D255E2.EB933A30]
James Gould
Distinguished Engineer
jgo...@verisign.com
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com<http://verisigninc.com/>
From: regext <regext-boun...@ietf.org> on behalf of Roger Carney
<rcar...@godaddy.com>
Date: Friday, May 4, 2018 at 12:33 PM
To: Registration Protocols Extensions <regext@ietf.org>
Subject: [EXTERNAL] [regext] REGEXT Interim Meeting
Good Morning,
I would like to invite everyone to an interim meeting Tuesday June 5th at 16:00
UTC for 60 minutes.
We plan to focus the discussion around two topics:
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.
We will once again use Zoom as a conferencing tool, please use this
link<https://godaddy.zoom.us/j/453206454> to connect to the meeting.
Please reply to the list or directly to myself if you plan on attending this
meeting.
Thanks
Roger
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
