Subject: [regext] Contact Postal Info Elements Proposal

From: "Gould, James" <[email-masked]>
Date: Fri, 31 Mar 2017 14:00:30 +0000

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.

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://verisigninc.com/>

---

From: Thomas Corte <[email-masked]>
Date: Fri, 31 Mar 2017 17:15:25 +0200

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  
> 
> b.      This includes the <contact:postalInfo>, <contact:voice>,
> <contact:fax>, <contact:email>, <contact:authInfo>, and the
> <contact:disclose> elements.
> 

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:    [email-masked]
     Software-Entwicklung        E-Mail: [email-masked]

                                 Registereintrag:
                                 Amtsgericht Dortmund, HRB 13728

                                 Geschäftsführer:
                                 Dietmar Knipp, Elmar Knipp

---

From: "Gould, James" <[email-masked]>
Date: Fri, 31 Mar 2017 15:24:18 +0000

Thomas,

Thanks for the response.  My feedback is embedded below.  I’ve updated the proposal based on your feedback:

c.            Servers with special policies regarding contact data modifications should check the new data for any actual changes in relevant fields.

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

[email-masked]

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" <[email-masked] on behalf of [email-masked]> wrote:

    Hello James,

    > a.       Existing sub-element data deleted first and then set with

    > updated data.

    > 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

    > Please comment on the proposal to help clarify the interpretation of EPP

    > RFC 5733.

      <command>

        <update>

            <id>HANDLE-1</id>

            <chg>

              <voice/>

              <fax/>

            </chg>

          </update>

        </update>

      </command>

    </epp>

JG – Yes, I included a reference to the voice and fax as well.

JG – Done, I borrowed you wording with this.

    repository.

JG – I believe you proposed wording for #1 above should cover this use case.

    Best regards,

    Thomas

    --

         |       |

          -------                    Technologiepark

                                     Martin-Schmeißer-Weg 9

                                     44227 Dortmund

                                     Deutschland

                                     Registereintrag:

                                     Geschäftsführer:

    _______________________________________________

    regext mailing list

    [email-masked]

    https://www.ietf.org/mailman/listinfo/regext

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 31 Mar 2017 17:57:13 +0200

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:
> 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>, 
> 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/>)
>
> On 3/31/17, 10:15 AM, "regext on behalf of Thomas Corte" 
> <[email-masked] on behalf of [email-masked]> wrote:
>
>     Hello James,
>

-- 
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: [email-masked]
Phone: +39 050 3153497
Web: http://www.iit.cnr.it/mario.loffredo