Thomas,
Thanks for the response. My feedback is embedded below. I’ve updated the proposal based on your feedback: 1. The <contact:chg> sub-elements do have replace semantics a. Existing sub-element data deleted first and then set with updated data. b. This includes the <contact:postalInfo>, <contact:voice>, <contact:fax>, <contact:email>, <contact:authInfo>, and the <contact:disclose> elements. c. Servers with special policies regarding contact data modifications should check the new data for any actual changes in relevant fields. 2. The typed <contact:postalInfo> elements (“int” or “loc”) are treated independently a. Exclusion of a <contact:postalInfo> type (“int” or “loc”) does not implicitly delete it 3. The typed <contact:postalInfo> element (“int” or “loc”) is deleted explicitly via an empty element a. <contact:postalInfo type=”int”/> or <contact:postalInfo type=”loc”/> b. The same applies to deleting the voice or the fax via an empty element (<contact:voice/> or <contact:fax/>) Let me know if any other changes are needed. Thanks, — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com <http://verisigninc.com/> On 3/31/17, 10:15 AM, "regext on behalf of Thomas Corte" <regext-boun...@ietf.org on behalf of thomas.co...@knipp.de> wrote: Hello James, On 31/03/2017 16:00, Gould, James wrote: > As an action item from the REGEXT WG meeting yesterday, I’m including my > proposal for handling the EPP RFC 5733 <contact:postalInfo> element on an > update: > > 1. The <contact:chg> sub-elements do have */replace/* semantics > > a. Existing sub-element data deleted first and then set with > updated data. > > b. This includes the <contact:postalInfo>, <contact:voice>, > <contact:fax>, <contact:email>, <contact:authInfo>, and the > <contact:disclose> elements. > > 2. The typed <contact:postalInfo> elements (“int” or “loc”) are > treated independently > > a. Exclusion of a <contact:postalInfo> type (“int” or “loc”) does > not implicitly delete it > > 3. The typed <contact:postalInfo> element (“int” or “loc”) is > deleted explicitly via an empty element > > a. <contact:postalInfo type=”int”/> or <contact:postalInfo type=”loc”/> > > Please comment on the proposal to help clarify the interpretation of EPP > RFC 5733. I agree with this interpretation. For the avoidance of (further) doubt, it might make sense to mention that the deletion of voice and fax numbers is also done via empty elements, i.e. like this: <?xml version="1.0" encoding="UTF-8"?> <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> <command> <update> <update xmlns="urn:ietf:params:xml:ns:contact-1.0"> <id>HANDLE-1</id> <chg> <voice/> <fax/> </chg> </update> </update> <clTRID>ABC-12345</clTRID> </command> </epp> JG – Yes, I included a reference to the voice and fax as well. Also, with these clarified semantics it's no longer possible to e.g. change a contact's name while retaining its organization without explicitly repeating the previous organization value. Therefore, I'd also suggest to put in some wording stressing that servers with special policies regarding contact data modifications should check the new data for any actual changes in relevant fields. JG – Done, I borrowed you wording with this. I'm suggesting this because some registries (most notably CNNIC) have special contact validation policies, so that e.g. certain registrant contact changes may trigger a re-validation, or might not even be allowed. At the moment, a contact update that needs to retain the organization for a CNNIC contact *must* be sent with the <org> element missing from the <update> request, otherwise the server assumes a change (even if the submitted value is identical to the currently present one) and triggers re-validation or rejects the update. The wording therefore should clarify that servers must not assume an actual data change just on the basis that an element is present in the <postalInfo> element; instead, the actual data must be compared to the current data in the repository. JG – I believe you proposed wording for #1 above should cover this use case. Best regards, Thomas -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland Dipl.-Informatiker Tel: +49 231 9703-0 Thomas Corte Fax: +49 231 9703-200 Stellvertretender Leiter SIP: thomas.co...@knipp.de Software-Entwicklung E-Mail: thomas.co...@knipp.de Registereintrag: Amtsgericht Dortmund, HRB 13728 Geschäftsführer: Dietmar Knipp, Elmar Knipp _______________________________________________ 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
