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

From: "Gould, James" <[email-masked]>
Date: Mon, 13 Feb 2017 13:33:00 +0000

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]> on behalf of "Hollenbeck, Scott" <[email-masked]>
Date: Monday, February 13, 2017 at 7:18 AM
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[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]; [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.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 13 Feb 2017 13:59:53 +0000

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,

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

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

Thanks in advance,

Santosh Kalsangrah

  _____

---

From: Thomas Corte <[email-masked]>
Date: Mon, 13 Feb 2017 15:28:24 +0100

Hello,

On 13/02/2017 14:59, Hollenbeck, Scott wrote:

> 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”.

If the idea were to completely replace all postal info by whatever
<postalInfo> elements are specified in the <chg> element, then there
would be no point in having a special - potentially completely empty -
"chgPostalInfoType" type in the schema there, since it allows the
addition of incomplete address data that could result in schema
violations for <contact:info> responses. This could just be
"postalInfoType" then to enforce the presence of mandatory fields.
This seems to indicate that the original idea was *not* a complete
replacement. This would otherwise also kind of contradict the way <chg>
is interpreted for domains (RFC 5731), since it would imply that one
could not change a domain's registrant without also changing or removing
a domain's authinfo string.

Note that this topic has been discussed before, starting at
https://www.ietf.org/mail-archive/web/provreg/current/msg07560.html
As a result of that discussion, our own EPP server implementation in the
TANGO Registry System does the following:

* if a <postalInfo> loc/int element is specified which is "empty"
  ("empty" being defined as: no org, no name, and mandatory address
  element "city" missing), the server removes that element from the
  contact
* if it is not empty, it completely replaces the respective loc/int data
* if the contact has loc/int data which is not present in the <chg>
  element, that data is retained, i.e. *not* removed

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbH                    Thomas Corte
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                      E-Mail: [email-masked]
Germany

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 13 Feb 2017 15:46:52 +0000

> -----Original Message-----
> From: regext [mailto:[email-masked]] On Behalf Of Thomas Corte
> Sent: Monday, February 13, 2017 9:28 AM
> To: [email-masked]
> > 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".
>
> <postalInfo> elements are specified in the <chg> element, then there would
> be no point in having a special - potentially completely empty -
> "chgPostalInfoType" type in the schema there, since it allows the addition
> of incomplete address data that could result in schema violations for
> <contact:info> responses. This could just be "postalInfoType" then to
> enforce the presence of mandatory fields.
> replacement. This would otherwise also kind of contradict the way <chg> is
> interpreted for domains (RFC 5731), since it would imply that one could
> not change a domain's registrant without also changing or removing a
> domain's authinfo string.

My apologies. I wrote the text more than 15 years ago, and after looking through the documents again I see that you're correct. As written, the schema and text support selective change. I'm not sure why or how we ended up there, but that's what we have. At least I'm consistent in my memory of my intentions:

https://www.ietf.org/mail-archive/web/provreg/current/msg07561.html

So back to the original question: I believe it's possible to remove one of the forms by replacing it with an empty value as described here:

https://www.ietf.org/mail-archive/web/provreg/current/msg07568.html

> <contact:update xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
>    <contact:id>C20131114-01</contact:id>
>    <contact:chg>
>      <contact:postalInfo type="int"/>
>    </contact:chg>
> </contact:update>

It looks schema-legitimate to me since all of the child elements of <contact:postalInfo> are optional.

Looking at all of this again I wish I had just used the same schema type for creates and updates and explicitly noted that a change is a 1-for-1 replacement. That would seem to be much simpler.

Scott

Scott

---

From: Mike O'Connell <[email-masked]>
Date: Tue, 14 Feb 2017 09:56:17 +0200

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
[email-masked]
www.dns.net.za
+27 11 568 2800

> On 13 Feb 2017, at 15:33, Gould, James <[email-masked]> wrote:
> 
> Scott,
>  
> [email-masked] <x-msg://22/[email-masked]>
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> VerisignInc.com <http://verisigninc.com/>
>  
> 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. <>
>  
> 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
>  
>  
> 
> 
> 
> 
> 
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext