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

"Gould, James" <jgould@verisign.com> Thu, 23 February 2017 14:44 UTC

Return-Path: <jgould@verisign.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F75412989B for <regext@ietfa.amsl.com>; Thu, 23 Feb 2017 06:44:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Zx9yS8JZ3EO for <regext@ietfa.amsl.com>; Thu, 23 Feb 2017 06:44:54 -0800 (PST)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425421297CA for <regext@ietf.org>; Thu, 23 Feb 2017 06:44:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=49308; q=dns/txt; s=VRSN; t=1487861095; h=from:to:subject:date:message-id:mime-version; bh=W6a99o2STTcb8QwFTN64vFioyuPuB9bfA4I7Asvu1GY=; b=PkXUrCYOXlEF5uPuC+JMt8hXzQeO6zq5odD4tsaCIlSPdfo9Y8Km6Dhn V72i185br1rOk9y9Xu4rzfqOEWOYWvoxJRWB37VrUNkMh/QK0HtH3RrC9 i5RidEh+HUb82WWA7R99u0Gu3XvnKYJ2csIFfMjFyS3KE/3+0DxEs0aAR LA0pxGl++7ji3FdroYSO8n3YHHlDQ6l0gfHuNvpxSHhBx8grPnqbPeoQP kEjpV7/BMorNtQisauWirnLtwHMpzHj0Zh+977qFhGiMvCZZZLsMUi1EA U1MLDDuvuoiXg+ZWctkK42VDU8fCC5rotcEc1WOMV+W2xk7Z9TcWDpU8x g==;
X-IronPort-AV: E=Sophos;i="5.35,198,1484006400"; d="png'150?scan'150,208,217,150";a="1614930"
IronPort-PHdr: 9a23:Xj8I2hV7vCl3KhuDskFKNiL6D9XV8LGtZVwlr6E/grcLSJyIuqrYZRWHtKdThVPEFb/W9+hDw7KP9fuxBCpZsd3f7zgrS99lb1c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUhrwOhBoKevrB4Xck9q41/yo+53Ufg5EmCexbal8IRiyrQjdrNQajIhtJqswyBbCv2dFdflRyW50P1yYggzy5t23/J5t8iRQv+wu+stdWqjkfKo2UKJVAi0+P286+MPkux/DTRCS5nQHSWUZjgBIAwne4x7kWJr6rzb3ufB82CmeOs32UKw0VDG/5KplVBPklCEKPCMi/WrJlsJ/kr5UoBO5pxx+3YHUZp2VNOFjda/ZZN8WWHZNUtpUWyFHH4iybZYAD/AZMOhYsYfzukcOoxW9CwaiBePg1jBHi2Ts3aEm1uQsCx3K0RYiEt8IrX/arM/1NKAXUe2twqXGzDLDb+5S2Tjg8ITDbxQvruuJXb1uasrdx1QkGgTHjlWfrozlIjeV2fkWvmiF8eVgT+Ovi3UmqwF+pDij3Nsjio7Mho8MzF3P6Ct3wIEwJdKiSU57Z8apEIVOuCGANot2WcIiQ25uuCog1rIGvpu7cDAUyJs53R7faueHc4mH4hLlVeaRJyt3iGh5d7K4gha+6UmgxfPgVsm6ylpKqTBFktbKu3sQ1BLT8tCKRuZh8ku7xDqC1Q7e5vtZLU00m6fXMYAtz7Ewm5YLrEjPAjX6lFj0gaKYbEko5+il5/r9brjpoJKXKpV6hRvkMqs0n8yyGeE4Mg8TUGeF4em8z7jj/VHhQLVNk/02jrHVsJDEKsQfoa60GxRa0pwl6xqiCzen39EYkmMGLFJBfxKHkpTpN03QLPziE/ewnU6skDZwx/DHMb3hBI/BIWTEkLfkZbp96khcxxQvzd1H+p5YFqsNLO/xV0L/rtDUEx80PgKuz+r5B9hw1psSWWeVDa+YNKPSv0WI5uUqI+SUZo8VtzH9K+Uh5/HzlnI5h0ESfbOo3ZsMaXC4EfJmL1+Fbnrrh9cNCX0KsRYmTOz2lF2CViZeZ2ysUKIz+D46B56mAJzCRo+znLyB0j23HppMZmBJElqMC2vnd52YW/cQbyKfOtRhnSYCVbi9TI8hzhGuuBX5y7V9KurU4TcXtZTs1Nhv/eLTlQo/9T1xD8SFzW6NU3x0nngSSzAq26Bzu019ylHQmZR/1rZ4EthX6vVDXww5cdbnxOtmF5q6DhnBedONRVCsT96lKS88VNMqwtAIJU16HoPmxlqMxCOsH7gOl/qIDZgv+6TTxXHxD8d403vaybJnhF5gQ80AfyXynad56w/IB8jKmkGCnqClb60c9C/I7Gqf0HHIt0YeUQgmFe2PEmoSaUbGsfz461/MCbi0Bvttel9bxMGPOrdia9D1gxNBXvi1a/rEZGfk0Ui3GBKEgvuuZY/nYC9ViCfSD1UAnygN8GyHLgkxAGGqpGeIX28mLk7mf065qbo2k3i8VEJhiljSN0A=
X-IPAS-Result: A2HmAADS9K5Y//WZrQpTBwMZAQEBAQEBAQEBAQEHAQEBAQEUAQEBAQEBAQEBAQEHAQEBAQGCQ4FDgQkHg1SKCJFbgmSSUIFKQyqFeAIag0UYAQEBAQEBAQEBAQECgQeCMyIBDD0GNgEBAQEBAQEBAQEBAR0CCDYSAQEYAQECAwUBHQIIAV0BBgINBAMBAQEGAQEBGAcDAgQFEA8MFAkKBAERAQ6HegOBeJAnnViCJiuLGAEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4Phk2CBIJqhCYGCwEGGwMECwgBAQYPEYI/LoIxBYl6hVOMQQYBhX4BdI0rU4RJiXqIN4pxH4ExCFQVTwGEOR2BYXUBAYkWgSGBDQEBAQ
Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id v1NEiptg010771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Feb 2017 09:44:52 -0500
Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Thu, 23 Feb 2017 09:44:50 -0500
From: "Gould, James" <jgould@verisign.com>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>, "'santosh.kalsangrah@impetus.co.in'" <santosh.kalsangrah@impetus.co.in>, "'regext@ietf.org'" <regext@ietf.org>
Thread-Topic: Re: [regext] Query: Remove contact:postalInfo from a contact
Thread-Index: AQHSjeNiu5b6vA5HEEKbqqbfPMs3sw==
Date: Thu, 23 Feb 2017 14:44:50 +0000
Message-ID: <934FF566-2BB7-4AF6-9F41-B7F4913D7147@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1f.0.170216
x-originating-ip: [10.173.152.4]
Content-Type: multipart/related; boundary="_005_934FF5662BB74AF69F41B7F4913D7147verisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/NGD6WvTFZgh_mY3twoFH2A-M5Ds>
Subject: Re: [regext] Query: Remove contact:postalInfo from a contact
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Feb 2017 14:44:57 -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

[cid:image001.png@01D28DB9.79ABBCD0]

James Gould
Distinguished Engineer
jgould@Verisign.com

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

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

From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Monday, February 13, 2017 at 8:59 AM
To: James Gould <jgould@verisign.com>, "'santosh.kalsangrah@impetus.co.in'" <santosh.kalsangrah@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 <shollenbeck@verisign.com>; 'santosh.kalsangrah@impetus.co.in' <santosh.kalsangrah@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
jgould@Verisign.com

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

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

From: regext <regext-bounces@ietf.org<mailto:regext-bounces@ietf.org>> on behalf of "Hollenbeck, Scott" <shollenbeck@verisign.com<mailto:shollenbeck@verisign.com>>
Date: Monday, February 13, 2017 at 7:18 AM
To: "'santosh.kalsangrah@impetus.co.in'" <santosh.kalsangrah@impetus.co.in<mailto:santosh.kalsangrah@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-bounces@ietf.org] On Behalf Of Santosh K Kalsangrah
Sent: Monday, February 13, 2017 5:08 AM
To: eppext@ietf.org<mailto:eppext@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.