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

Klaus Malorny <Klaus.Malorny@knipp.de> Fri, 15 November 2013 09:01 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 64DC111E810A for <provreg@ietfa.amsl.com>; Fri, 15 Nov 2013 01:01:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 AfI+ucsTVtjC for <provreg@ietfa.amsl.com>; Fri, 15 Nov 2013 01:01:48 -0800 (PST)
Received: from kmx10a.knipp.de (clust3b.bbone.knipp.de [195.253.6.85]) by ietfa.amsl.com (Postfix) with ESMTP id E98B711E8102 for <provreg@ietf.org>; Fri, 15 Nov 2013 01:01:47 -0800 (PST)
Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 52BE957; Fri, 15 Nov 2013 10:01:45 +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 RQgy3+1xNd-m; Fri, 15 Nov 2013 10:01:28 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 21E8051; Fri, 15 Nov 2013 10:01:23 +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 rAF91LBC020321; Fri, 15 Nov 2013 10:01:22 +0100 (MEZ)
Message-ID: <5285E2E8.7020304@knipp.de>
Date: Fri, 15 Nov 2013 10:01:28 +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: "Hollenbeck, Scott" <shollenbeck@verisign.com>, Seth Goldman <sethamin@google.com>
References: <5284EE10.5020809@knipp.de> <FE61FDF5-1A84-49FE-AF85-463317EF0BDC@verisign.com> <CAAHh_-L2Zopu=LygHbUzgHhWs9N3i8tfWLif2yJraxbYCF-JGg@mail.gmail.com> <831693C2CDA2E849A7D7A712B24E257F492D517E@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F492D517E@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
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: Fri, 15 Nov 2013 09:01:54 -0000

On 14.11.2013 19:48, Hollenbeck, Scott wrote:
> I don’t know how one can make a case that sub-element replacement is acceptable.
> Section 3.2.5 of RFC 5733 says this (emphasis mine):
>
> “The EPP <update> command provides a transform operation that allows a client to
> modify the attributes of a contact _/object/_.”
>
> and this:
>
> “An OPTIONAL <contact:chg> element that contains _/object attribute values to be
> changed/_.”
>
> The <update> is thus focused on _/changing/_ the attributes of the _/object/_.
> In the example Klaus provided, the command received is “replace the existing
> <contact:postalInfo> attribute with a new instance of <contact:postalInfo>”. The
> server failed to replace the two <street> elements with the single element
> provided in the <update>. It shouldn’t work that way.
>
> Scott
>

Hi Scot, Seth,

up to now I regarded the name, the organization and the the whole address block 
as the replacable units, derived from the associated XML schema. It namely 
contains two datatypes, "postalInfoType" for the create command and 
"chgPostalInfoType" for the update command. The first contains the <name> and 
<addr> elements as mandatory elements, the latter contains them as optional 
elements. If one would consider the postalInfo itself as the replacable unit, it 
would not make sense to enforce the name and address on <create>, but would 
allow to remove them with a following <update> request.

So simply asked: What does the following schema-wise legal request do?

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

Does it clear the international contact? Does it leave the international postal 
data simply unchanged (aside from being illegal in Scot's view to submit a 
command that is effectively non-modifying). Does the following command

<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:org>ACME Solutions</contact:org>
     </contact:postalInfo>
   </contact:chg>
</contact:update>

modify the postal info so that it *solely* contains the organization and nothing 
else afterwards?

Regards,

Klaus