Subject: Re: [regext] REGEXT Interim Meeting

From: "Gould, James" <[email-masked]>
Date: Mon, 4 Jun 2018 17:56:21 +0000

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

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: regext <[email-masked]> on behalf of Roger Carney <[email-masked]>
Date: Friday, May 4, 2018 at 12:33 PM
To: Registration Protocols Extensions <[email-masked]>
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

---

From: Roger D Carney <[email-masked]>
Date: Tue, 5 Jun 2018 15:47:14 +0000

Good Morning,

This is great, thanks Jim for the thorough review and comments.

We can use this set of items to start our discussions today.

Thanks
Roger

From: Gould, James [mailto:[email-masked]]
Sent: Monday, June 04, 2018 12:56 PM
To: Roger D Carney <[email-masked]>; Registration Protocols Extensions <[email-masked]>
Subject: Re: [regext] REGEXT Interim Meeting

Roger,

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

From: regext <[email-masked]<mailto:[email-masked]>> on behalf of Roger Carney <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 4, 2018 at 12:33 PM
To: Registration Protocols Extensions <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] [regext] REGEXT Interim Meeting

Good Morning,

Agenda

Thanks

Roger

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 06 Jun 2018 02:08:58 +0200

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

---

From: "Gould, James" <[email-masked]>
Date: Wed, 6 Jun 2018 12:21:59 +0000

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
[email-masked]

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" <[email-masked] on behalf of [email-masked]> wrote:

    

    -- 
      Patrick Mevzek
    
    _______________________________________________
    regext mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: Patrick Mevzek <[email-masked]>
Date: Sat, 09 Jun 2018 08:03:41 +0200

On Wed, Jun 6, 2018, at 14:21, Gould, James wrote:
> This dependency 
> does require ensuring that the host XML schema is loaded ahead of the 
> domain XML schema when pre-caching the XML schemas.

So it seems having dependencies is only a problem or a difficulty when validating the frames per the schemas.

-- 
  Patrick Mevzek

---

From: Pieter Vandepitte <[email-masked]>
Date: Mon, 11 Jun 2018 08:52:06 +0000

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" <[email-masked] on behalf of jgould=[email-masked]> wrote:

    Patrick,

    —
     
    JG

    James Gould
    Distinguished Engineer
    [email-masked]
    
    703-948-3271
    12061 Bluemont Way
    Reston, VA 20190

    

        
        
        -- 
          Patrick Mevzek

---

From: "Gould, James" <[email-masked]>
Date: Mon, 11 Jun 2018 12:30:37 +0000

Patrick,

Yes, the issue is associated with the loading of the XML schemas and validating the XML against them.  There is also a potential code (library) dependency based on where the dependent XML schema (e.g., host-1.0.xsd for the domain mapping) lives.  In looking at the Verisign EPP SDK, there is a directory per mapping or set of extensions that includes the XML schemas to load and validate against with a set of tests that are isolated to that mapping or set of extensions.  By adding an inter-mapping / extension dependency, you either need to copy the dependent XML schemas or create a build dependency.  This is not a huge technical issue, but is certainly an annoyance that is only worth it if the dependency is truly warranted.  I view the Validate Extension as being on the borderline of justifying the dependency, which is why I wanted to bring it up.  The Validate Extension also added the extra complexity of requiring the use of the contact namespace directly in the XML (e.g., <validate:postalInfo type="int"><contact:name>John Doe</contact:name>...</validate:postalInfo>) based on the use of complex types in the contact XML schema.  Again, it is not a huge technical issue to support two XML namespaces in the Validate extension, but it is a factor to consider.  

Thanks,
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 6/9/18, 2:03 AM, "Patrick Mevzek" <[email-masked]> wrote:

    
    -- 
      Patrick Mevzek