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

Klaus Malorny <Klaus.Malorny@knipp.de> Mon, 18 November 2013 11:52 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 2C25711E8198 for <provreg@ietfa.amsl.com>; Mon, 18 Nov 2013 03:52:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.43
X-Spam-Level:
X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_05=-1.11, 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 P32yFeT7ndfh for <provreg@ietfa.amsl.com>; Mon, 18 Nov 2013 03:52:34 -0800 (PST)
Received: from kmx10a.knipp.de (clust3b.bbone.knipp.de [195.253.6.85]) by ietfa.amsl.com (Postfix) with ESMTP id CC60711E80FB for <provreg@ietf.org>; Mon, 18 Nov 2013 03:52:33 -0800 (PST)
Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 3681C49; Mon, 18 Nov 2013 12:52:31 +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 a68sKHIU1Pg3; Mon, 18 Nov 2013 12:52:23 +0100 (MEZ)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 61D964A; Mon, 18 Nov 2013 12:52: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 rAIBqMrC015987; Mon, 18 Nov 2013 12:52:22 +0100 (MEZ)
Message-ID: <5289FF75.6060501@knipp.de>
Date: Mon, 18 Nov 2013 12:52:21 +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: "Gould, James" <JGould@verisign.com>, "james.mitchell@ausregistry.com.au" <james.mitchell@ausregistry.com.au>, Seth Goldman <sethamin@google.com>, "Hollenbeck, Scott" <shollenbeck@verisign.com>
References: <CEAB90ED.51E41%jgould@verisign.com>
In-Reply-To: <CEAB90ED.51E41%jgould@verisign.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Mon, 18 Nov 2013 11:52:50 -0000

On 15.11.2013 15:04, Gould, James wrote:
> I agree that it changes/modifies the elements specified, where I view the
> elements as being the direct child elements of <contact:chg>, which include:
>
>  1. <contact:postalInfo> with type attribute as being relevant
>      1. For example, if a contact had both types of postalInfo, inclusion of
>         only one of the types ("int" or "loc") under the <contact:chg> does not
>         implicitly remove the other type.
>      2. All sub-elements of the <contact:postalInfo> with type would be replaced
>         including the two streets to one street example.

ok, I think that makes most sense. Missing subelements within the <postalInfo> 
element shall be regarded in the same way as during the <contact:create>, i.e. 
as an empty, "not specified" value that replaces any previous value. The 
elements <name>, <city> and <cc> elements may not be excluded for a general 
update, as they are mandatory. The <name> and <addr> elements may only be 
omitted along with the <org> element, which indicates that the respective 
<postalInfo> version shall be removed from contact as a whole.

Thanks all for the participation.

Regards,

Klaus