Re: [provreg] RFC 5733: street changes with contact:update
齐超 <qichao@cnnic.cn> Fri, 15 November 2013 09:49 UTC
Return-Path: <qichao@cnnic.cn>
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 734BB11E810D for <provreg@ietfa.amsl.com>;
Fri, 15 Nov 2013 01:49:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.612
X-Spam-Level:
X-Spam-Status: No, score=-96.612 tagged_above=-999 required=5 tests=[AWL=3.827,
BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3,
USER_IN_WHITELIST=-100]
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 WYd-g6BQ26l8 for
<provreg@ietfa.amsl.com>; Fri, 15 Nov 2013 01:48:59 -0800 (PST)
Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com
(Postfix) with SMTP id 9E64911E8102 for <provreg@ietf.org>;
Fri, 15 Nov 2013 01:48:57 -0800 (PST)
X-EYOUMAIL-SMTPAUTH: qichao@cnnic.cn
Received: from unknown218.241.111.100 (HELO qichao) (218.241.111.100) by
218.241.118.7 with SMTP; Fri, 15 Nov 2013 17:48:53 +0800
Date: Fri, 15 Nov 2013 17:48:55 +0800
Organization: CNNIC
From: =?utf-8?B?6b2Q6LaF?= <qichao@cnnic.cn>
To: "Klaus Malorny" <Klaus.Malorny@knipp.de>
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>,
<5285E2E8.7020304@knipp.de>
X-Priority: 3
X-Mailer: Foxmail 7.0.1.76[cn]
Mime-Version: 1.0
Message-ID: <20131115174854953765161@cnnic.cn>
Content-Type: multipart/alternative;
boundary="----=_001_NextPart608215171534_=----"
Cc: "provreg@ietf.org" <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:49:04 -0000
Hello Klaus,
In my opinion , <contact:rem> will be used to clear a postalInfo if regsitrar wants to remove it .
So for request 1, nothing changed for lacking necessary values, for request 2, only organization of type 'int' will be updated.
齐超 via foxmail
发件人: Klaus Malorny
发送时间: 2013年11月15日(星期五) 下午5:01
收件人: Hollenbeck, Scott; Seth Goldman
抄送: IETF Provreg Mailing List
主题: Re: [provreg] RFC 5733: street changes with contact:update
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
_______________________________________________
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