Pieter,
Regardless of that, I’m still trying to figure out the use of this extension. Will a client first check whether a contact can be created, then interpret the response of the check, and finally create the command. Or will the client just try to create the contact, and in case of error interpret the error message? Maybe there’s a need for better, more structured and machine interpretable responses, but I don’t think the extra check step is the way to go. Just my 2 cents… Based on my deep dive into draft-ietf-regext-validate, my take of the draft is that it’s used to validate the use of an existing or new contact as a contact type for a domain name of a tld. A little of the confusion discussed during the REGEXT Interim Meeting was how the client specifies the use of an existing or new contact. One assumption that I made was the reference to an existing contact was made by only including a contact id (<validate:id>) and definition of a new contact to validate was made by the inclusion of the additional contact attributes (<contact:postalInfo>, etc.). That was not the case, since the extension supported reuse of new contact attributes for a different contact type and tld by referencing a contact id included earlier in the check command. Take a look at the use of the “sh8013” contact id in the check command example, where it’s fully defined for the “registrant” type and the “COM” tld, but only referenced by contact ID for the subsequent “tech” type and “COM” tld. Also notice that the contacts are consolidated in the check response by contact ID. In the validate check command there are 4 contacts and the validate check response has only two. My recommendation was to support referencing an existing contact by only supplying the contact ID, don’t create dependencies between check items to reduce the amount of duplicate information provided, and ensure that the number of items in the check response match the number of items in the check command. — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 6/11/18, 4:53 AM, "Pieter Vandepitte" <pieter.vandepi...@dnsbelgium.be> wrote: Maybe I’m missing something, but this draft is about validating contacts, so I don't see an issue in referring to the contact RFC. There’s no point in validating contacts, but not creating them, so the client needs to support the contact xsd anyway. Regardless of that, I’m still trying to figure out the use of this extension. Will a client first check whether a contact can be created, then interpret the response of the check, and finally create the command. Or will the client just try to create the contact, and in case of error interpret the error message? Maybe there’s a need for better, more structured and machine interpretable responses, but I don’t think the extra check step is the way to go. Just my 2 cents… Kind regards -- Pieter Vandepitte Product Expert +32 16 28 49 70 www.dnsbelgium.be On 06/06/18 14:22, "regext on behalf of Gould, James" <regext-boun...@ietf.org on behalf of jgould=40verisign....@dmarc.ietf.org> wrote: Patrick, The base EPP protocol is defined using epp and eppcom, where extensions (object or command / response) would naturally be dependent on the base schemas. Creating dependencies across extensions does not allow them to stand on their own, so my preference would be to copy and paste the elements from sibling extension XML schemas unless there is a large advantage with creating the dependency. There are examples of cross extension dependencies that exist today, like the inclusion of the host XML schema within the domain XML schema of RFC 5731. This dependency does require ensuring that the host XML schema is loaded ahead of the domain XML schema when pre-caching the XML schemas. The contact reference in the validate extension takes it one step further by referencing complex types that requires the use of the contact namespace directly within the XML, so it's more than just ensuring that the contact XML schema is loaded ahead of the validate XML schema. It is not hard to overcome, but I believe the priority should be to have the extensions stand on their own and only be dependent on the base XML schemas of epp and eppcom unless there is an overriding reason to add the cross-extension dependency. — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 6/5/18, 8:09 PM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: On Mon, Jun 4, 2018, at 19:56, Gould, James wrote: > 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. I am sure that not all elements of epp/eppcom namespaces are used either so under symmetry and consistency I would find more logical that all schemas are treated the same, either all referenced, or all copied (for the parts needed). And I see no problems in referencing the contact-1.0 one. Using epp/eppcom as references already make the schema dependent on other resources and not "standing on its own". I am not sure this has a huge consequence on implementations, especially if taking into account multiple ways to implement things (and especially doing validation or not). -- Patrick Mevzek _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
