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 [cid:image001.png@01D28DB9.79ABBCD0] James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://verisigninc.com/> From: "Hollenbeck, Scott" <shollenb...@verisign.com> Date: Monday, February 13, 2017 at 8:59 AM To: James Gould <jgo...@verisign.com>, "'santosh.kalsang...@impetus.co.in'" <santosh.kalsang...@impetus.co.in>, "'regext@ietf.org'" <regext@ietf.org> 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 <shollenb...@verisign.com>; 'santosh.kalsang...@impetus.co.in' <santosh.kalsang...@impetus.co.in>; 'regext@ietf.org' <regext@ietf.org> 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 [cid:image002.png@01D28DB9.79ABBCD0] James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://verisigninc.com/> From: regext <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org>> on behalf of "Hollenbeck, Scott" <shollenb...@verisign.com<mailto:shollenb...@verisign.com>> Date: Monday, February 13, 2017 at 7:18 AM To: "'santosh.kalsang...@impetus.co.in'" <santosh.kalsang...@impetus.co.in<mailto:santosh.kalsang...@impetus.co.in>>, "'regext@ietf.org'" <regext@ietf.org<mailto:regext@ietf.org>> 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:regext-boun...@ietf.org] On Behalf Of Santosh K Kalsangrah Sent: Monday, February 13, 2017 5:08 AM To: epp...@ietf.org<mailto:epp...@ietf.org>; regext@ietf.org<mailto:regext@ietf.org> 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.
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
