Subject: Re: [regext] Query: Remove contact:postalInfo from a contact

From: "Gould, James" <[email-masked]>
Date: Thu, 23 Feb 2017 14:44:50 +0000

Scott,

One additional nuance with interpreting the elements under <contact:chg> as a replace is that the chgPostalInfoType should have the “name” and “addr” elements as required, since the “name” element is required within the postalInfoType and the “addr” element with the addrType includes the required “city” and “cc” elements.  If an <contact:update> is provided with a <contact:postalInfo> element without a <contact:name> or a <contact:addr> element, then server should fail the update, since the required attributes (“name”, “city”, and “cc”) cannot be removed.

As far as the handling of the multiple postal info elements (“int” or “loc”), your interpretation is that inclusion of any <contact:postalInfo> elements on a <contact:update> replaces all of the existing postal information with what is provided.  So if both the <contact:postalInfo type=”int”> and <contact:postalInfo type=”loc”> elements are set, sending an update with just <contact:postalInfo type=”int”> will implicitly delete <contact:postalInfo type=”loc”> and replace the previous <contact:postalInfo type=”int”> with the <contact:postalInfo type=”int”> provided in the update.  In this case, the <contact:postalInfo> types are not treated independently but as a set, so there is no need for the client to pass an empty <contact:postalInfo type=”int|loc”> to explicitly delete it?

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Monday, February 13, 2017 at 8:59 AM
To: James Gould <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: [EXTERNAL] Re: [regext] Query: Remove contact:postalInfo from a contact

Jim, the change option should be interpreted as “completely replace old value with this new value”. Whatever postalInfo is provided with an update should completely replace whatever was there before. Looking at the use case you described, yes, you can replace <contact:postalInfo type=”int”> with <contact:postalInfo type=”loc”> by including the “loc” value in the <contact:chg> element. If that’s not clear it’s only because I didn’t think the meaning of “change” was ambiguous. That’s why there’s nothing there to selectively identify the values to be altered – “change” means “completely replace”.

Scott

From: Gould, James
Sent: Monday, February 13, 2017 8:33 AM
To: Hollenbeck, Scott <[email-masked]>; [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: Re: [EXTERNAL] Re: [regext] Query: Remove contact:postalInfo from a contact

Scott,

I believe the issue is that the only reference to <contact:postalInfo> in the <contact:update> command is under the <contact:chg> element.  I don’t believe the absence of a <contact:postalInfo> element of a specific type (“int” or “loc”) under <contact:chg> indicates an implicit delete.  Consider the use case:

1.       Create a contact via <contact:create> with a single <contact:postalInfo type=”int”>

2.       How do you replace the <contact:postalInfo type=”int”> with <contact:postalInfo type=”loc”> via the <contact:update>?

a.       Is it done by the inclusion of <contact:postalnfo type=”loc”> in the <contact:chg>, where the inclusion of at least one <contact:postalInfo> elements does an implicit change of all of the postal info data thus implicitly deleting <contact:postalInfo type=”int”> with <contact:postalInfo type=”loc”>?

Santosh brings up a similar use case of initially setting both <contact:postalInfo> types in the <contact:create>.  What it comes down to is whether inclusion of the <contact:postalInfo> element(s) under the <contact:chg> of the <contact:update> only changes the attributes of the specific types included or does it change all postal info data with an implicit delete and replace.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

From: regext <[email-masked]<mailto:[email-masked]>> on behalf of "Hollenbeck, Scott" <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 13, 2017 at 7:18 AM
To: "[email-masked]'" <[email-masked]<mailto:[email-masked]>>, "[email-masked]'" <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [regext] Query: Remove contact:postalInfo from a contact

The XML schema requires at least one instance and at most two instances of the postalInfo element. The “type” attribute (whose value is either “int” or “loc”) is required, but you don’t have to have both types present. You can always remove one or the other.

Having said that, I don’t think I’m answering your question. Could you please share examples of the state you’re starting with and the state you’re trying to achieve?

Scott

From: regext [mailto:[email-masked]] On Behalf Of Santosh K Kalsangrah
Sent: Monday, February 13, 2017 5:08 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] [regext] Query: Remove contact:postalInfo from a contact

Greeting EPP authors/users,

Seeking your input on EPP contact element <contact:postalInfo>. Could you please share if there any EPP way to remove “int” or “loc” postalinfo from a contact having both postalinfo types associated.

Referred EPP contact mapping RFC (https://tools.ietf.org/html/rfc5733#section-3.2.5 ) but there is no information of how can this done.

Thanks in advance,
Santosh Kalsangrah

________________________________

NOTE: This message may contain information that is confidential, proprietary, privileged or otherwise protected by law. The message is intended solely for the named addressee. If received in error, please destroy and notify the sender. Any use of this email is prohibited when received in error. Impetus does not represent, warrant and/or guarantee, that the integrity of this communication has been maintained nor that the communication is free of errors, virus, interception or interference.