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>
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.
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.
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
