Dear james,
I don't know if a further clarification is needed about the change of
the address property.
For me it is clear that, since cc and city are mandatory, the only way
to change an address is to define a new address reporting all the
relevant information (mandatory or not).
In this case, the lack of an optional field (previously not-empty) means
it will be considered empty.
Mario.
Il 31/03/2017 17:24, Gould, James ha scritto:
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
--
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: mario.loffr...@iit.cnr.it
Phone: +39 050 3153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
