Re: [provreg] RFC 5733: street changes with contact:update
"Hollenbeck, Scott" <shollenbeck@verisign.com> Thu, 14 November 2013 17:01 UTC
Return-Path: <shollenbeck@verisign.com>
X-Original-To: provreg@ietfa.amsl.com
Delivered-To: provreg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix)
with ESMTP id 4F4BA21E80E3 for <provreg@ietfa.amsl.com>;
Thu, 14 Nov 2013 09:01:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.562
X-Spam-Level:
X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.037,
BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8nNWD1RkyvG for
<provreg@ietfa.amsl.com>; Thu, 14 Nov 2013 09:01:04 -0800 (PST)
Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234])
by ietfa.amsl.com (Postfix) with ESMTP id F01CC11E815B for <provreg@ietf.org>;
Thu, 14 Nov 2013 09:01:00 -0800 (PST)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by
exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID
DSNKUoUBy9KndbdMA+7YCpspZKvCLfUkdQHn@postini.com;
Thu, 14 Nov 2013 09:01:02 PST
Received: from brn1wnexcas01.vcorp.ad.vrsn.com
(brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com
(8.13.6/8.13.4) with ESMTP id rAEH0xJ6010160 (version=TLSv1/SSLv3
cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 12:00:59 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by
brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003;
Thu, 14 Nov 2013 12:00:58 -0500
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: Klaus Malorny <Klaus.Malorny@knipp.de>
Thread-Topic: [provreg] RFC 5733: street changes with contact:update
Thread-Index: AQHO4U+hsqdvOPg/FUSJFbOtlkz9Bpok844/
Date: Thu, 14 Nov 2013 17:00:58 +0000
Message-ID: <FE61FDF5-1A84-49FE-AF85-463317EF0BDC@verisign.com>
References: <5284EE10.5020809@knipp.de>
In-Reply-To: <5284EE10.5020809@knipp.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF Provreg Mailing List <provreg@ietf.org>
Subject: Re: [provreg] RFC 5733: street changes with contact:update
X-BeenThere: provreg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: EPP discussion list <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>,
<mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/provreg>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>,
<mailto:provreg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Nov 2013 17:01:09 -0000
A change implies "replace all", Klaus. Scott > On Nov 14, 2013, at 10:38 AM, "Klaus Malorny" <Klaus.Malorny@knipp.de> wrote: > > > Hi all, > > a user of our registrar services discovered a strange behaviour with contact updates. Tracking down the problem, I determined that the respective registry is handling the <contact:update> differently to they way I expected and to the way we implemented this in our own registry software. Unfortunately, RFC 5733 does not specify the update in that depth, so I would like to know what was originally intended or is regarded as best practice. > > The problem refers to the streets in the contact. As you know, you can specify up to three line withing the address block. > > If one the <contact:create> request creates a contact with two lines, e.g. > > <contact:create xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> > <contact:id>C20131114-01</contact:id> > <contact:postalInfo type="int"> > <contact:name>John Doe</contact:name> > <contact:org>ACME Solutions</contact:org> > <contact:addr> > <contact:street>100 Centre St</contact:street> > <contact:street>second line</contact:street> > <contact:city>Townsville</contact:city> > <contact:sp>County Derry</contact:sp> > <contact:pc>Z1Z 1Z1</contact:pc> > <contact:cc>CA</contact:cc> > </contact:addr> > </contact:postalInfo> > ... > > and later issues an update a <contact:update> with only one line, e.g. > > <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:name>John Doe</contact:name> > <contact:org>ACME Solutions</contact:org> > <contact:addr> > <contact:street>200 Centre St</contact:street> > <contact:city>Townsville</contact:city> > <contact:sp>County Derry</contact:sp> > <contact:pc>Z1Z 1Z1</contact:pc> > <contact:cc>CA</contact:cc> > </contact:addr> > </contact:postalInfo> > ... > > what shall be the outcome? The registry in question only replaces the first street line, retaining the second line: > > <contact:postalInfo type='int'> > <contact:name>John Doe</contact:name> > <contact:org>ACME Solutions</contact:org> > <contact:addr> > <contact:street>200 Centre St</contact:street> > <contact:street>second line</contact:street> > <contact:city>Townsville</contact:city> > <contact:sp>County Derry</contact:sp> > <contact:pc>Z1Z 1Z1</contact:pc> > <contact:cc>CA</contact:cc> > </contact:addr> > </contact:postalInfo> > > However, I expected the old streets to be fully replaced. Or to be more clear, that the whole address block is replaced if given, meaning that if some of the data within is not given (e.g. <sp>), it is implicitly cleared. > > So what is correct and what is wrong, what is the smallest unit that can individually be replaced while leaving other data unchanged? > > Thanks for any input. > > Regards, > > Klaus > > > > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg
- [provreg] RFC 5733: street changes with contact:u… Klaus Malorny
- Re: [provreg] RFC 5733: street changes with conta… Hollenbeck, Scott
- Re: [provreg] RFC 5733: street changes with conta… Seth Goldman
- Re: [provreg] RFC 5733: street changes with conta… Hollenbeck, Scott
- Re: [provreg] RFC 5733: street changes with conta… 齐超
- Re: [provreg] RFC 5733: street changes with conta… Klaus Malorny
- Re: [provreg] RFC 5733: street changes with conta… Klaus Malorny
- Re: [provreg] RFC 5733: street changes with conta… 齐超
- Re: [provreg] RFC 5733: street changes with conta… Hollenbeck, Scott
- Re: [provreg] RFC 5733: street changes with conta… Seth Goldman
- Re: [provreg] RFC 5733: street changes with conta… James Mitchell
- Re: [provreg] RFC 5733: street changes with conta… Gould, James
- Re: [provreg] RFC 5733: street changes with conta… Klaus Malorny