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. > 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 > [email protected] <mailto:[email protected]>. 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. 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. 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: [email protected] Germany _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
