[provreg] RFC 5733: street changes with contact:update

Klaus Malorny <Klaus.Malorny@knipp.de> Thu, 14 November 2013 15:38 UTC

Return-Path: <Klaus.Malorny@knipp.de>
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 3683011E8164 for <provreg@ietfa.amsl.com>; Thu, 14 Nov 2013 07:38:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 1YZlJaHwGKlU for <provreg@ietfa.amsl.com>; Thu, 14 Nov 2013 07:38:36 -0800 (PST)
Received: from kmx10a.knipp.de (clust3c.bbone.knipp.de [195.253.6.130]) by ietfa.amsl.com (Postfix) with ESMTP id F11D421F9D8B for <provreg@ietf.org>; Thu, 14 Nov 2013 07:36:51 -0800 (PST)
Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 4198448; Thu, 14 Nov 2013 16:36:50 +0100 (MEZ)
X-Knipp-VirusScanned: Yes
Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id RMlpmNCr7pgx; Thu, 14 Nov 2013 16:36:42 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 0327D49; Thu, 14 Nov 2013 16:36:42 +0100 (MEZ)
Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id rAEFafBH003387; Thu, 14 Nov 2013 16:36:41 +0100 (MEZ)
Message-ID: <5284EE10.5020809@knipp.de>
Date: Thu, 14 Nov 2013 16:36:48 +0100
From: Klaus Malorny <Klaus.Malorny@knipp.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Thunderbird/28.0a1
MIME-Version: 1.0
To: IETF Provreg Mailing List <provreg@ietf.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [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 15:38:43 -0000

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