Thomas,
Thank you for your feedback. My responses are embedded below. -- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 8/3/21, 5:15 AM, "Thomas Corte (TANGO support)" <thomas.co...@knipp.de> wrote: Hello, On 8/2/21 20:08, Gould, James wrote: > Thomas, > > For use case #2 (info response of EAI address with non-EAI supporting > client), your preference is to return a failure. Is 2308 “data > management policy violation” the best error code in your opinion? While not ideal, it seems to be the most suitable one among the codes in RFC 5730, yes. Semantically, 2305 "Object association prohibits operation" seems even better, but it's clearly supposed to be used for responses to transform commands only. JG - In re-reviewing the list of possible error codes, it looks like 2308 "Data management policy violation" with the below description best matches the use case: This response code MUST be returned when a server receives a command whose execution results in a violation of server data management policies. For example, removing all attribute values or object associations from an object might be a violation of a server's data management policies. The data management policy violation is retuning a data format that is not supported by the querying client. Data management does not need to be isolated to an issue on the server-side, but could apply to proactively addressing a data issue in the client by returning a known unsupported data element. It’s not a perfect match but it’s the closest one in my opinion. > For use case #1, what is your proposal for the value that the sponsoring > registrar should provide with the create command to a non-EAI supporting > server? I see the following options: > > 1. ASCII placeholder value – The current proposal is the use of > e...@empty.as112.arpa <mailto:e...@empty.as112.arpa>. The assumption > is that using a placeholder value is not the preferred option based > on your feedback on use case 2. > 2. Collect ASCII value from registrant – This is counter to the goal of > supporting EAI, so it would only be done to pass a compliant value to > a non-EAI supporting server. > 3. Use proxy ASCII value – The EAI registrar would need to be able to > support EAI registrants and mix for EAI-supporting registries by > providing a ASCII proxy value to a non-EAI-supporting registry. The > proxy value to use would be up to registrar policy. > 4. A mix of the above options. 2. and 3. would be my preferred options. 2. seems OK as it's not unusual for registrars to collect different data for different registries to represent the same contact due to the varying data requirements, e.g. for widely differing authinfo string rules. JG – I’m believe option 2 is counter to the support of EAI, but this is only during a transition period. My thought is to provide option 2 and 3 for the registrar to choose from for this corner case where the server doesn’t support EAI but the registrar has EAI data. Also, while I understand the hesitation, I'm inclined to agree with other participants in this discussion in that, going forward, a new "contact-2.0" schema version for EPP contacts may be the best option here. While we're at it, we could also use the opportunity to eliminate some of the confusion that arose from unclear update semantics for address data, or to make the contact authinfo optional (as many registries don't support it anyway), among other things. JG – The approach had been discussed in the WG. The EAI issue goes beyond RFC 5733, since there is the use of an email element in RFC 8543, as well as proprietary extensions such as the Email Forwarding Mapping (https://www.verisign.com/assets/email-forwarding-mapping.pdf?inc=www.verisigninc.com). EAI support is a crosscutting EPP issue that is served by the definition of the functional extension in draft-ietf-regext-epp-eai. The case for a contact mapping update can be handled separately. Best regards, Thomas -- TANGO REGISTRY SERVICES® is a product of: Knipp Medien und Kommunikation GmbH Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: supp...@tango-rs.com Germany
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
