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 <regext-boun...@ietf.org> on behalf of Roger D Carney <rcar...@godaddy.com> Date: Tuesday 3 July 2018 at 20:04 To: Registration Protocols Extensions <regext@ietf.org> 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 regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
