We’ve discussed this issue internally at length and found that registrar implementations vary considerably in how they implement “int” vs “loc”.
Some of our registrars lazily implement one type while others use both. This leads to problems following transfers of contacts where the gaining registrar’s system cannot remove the, now defunct, alternative type. This also has further repercussions when establishing the legal entity because the “int” and “loc” values are now out of sync. Our solution to this is to remove the alternative type when a contact update, containing a single //contact:postalInfo, is received. Regards, Mike O’Connell Domain Name Services (Pty) Ltd m...@dns.net.za www.dns.net.za +27 11 568 2800 > On 13 Feb 2017, at 15:33, Gould, James <jgo...@verisign.com> wrote: > > 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 > > <image001.png> > > James Gould > Distinguished Engineer > jgo...@verisign.com <x-msg://22/jgo...@verisign.com> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > VerisignInc.com <http://verisigninc.com/> > > From: regext <regext-boun...@ietf.org> on behalf of "Hollenbeck, Scott" > <shollenb...@verisign.com> > Date: Monday, February 13, 2017 at 7:18 AM > To: "'santosh.kalsang...@impetus.co.in'" <santosh.kalsang...@impetus.co.in>, > "'regext@ietf.org'" <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; 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 > <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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
