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

Seth Goldman <sethamin@google.com> Thu, 14 November 2013 17:22 UTC

Return-Path: <sethamin@google.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 B697A21E8098 for <provreg@ietfa.amsl.com>; Thu, 14 Nov 2013 09:22:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level:
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 7c5CypGsp+ij for <provreg@ietfa.amsl.com>; Thu, 14 Nov 2013 09:22:26 -0800 (PST)
Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C19A921E80F1 for <provreg@ietf.org>; Thu, 14 Nov 2013 09:22:25 -0800 (PST)
Received: by mail-ve0-f171.google.com with SMTP id cz12so2102212veb.2 for <provreg@ietf.org>; Thu, 14 Nov 2013 09:22:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VTLXD5blFj23fdA7iuzbe11nPUGazX219WaDT87KGDQ=; b=ffELokXr+PhmycLrWK4eJFUovOpO/9R6teluihRVgv5KtEI7DIngYXIv/XQlGUG1n2 1C3YHPocD6UHyo6VQNiTAihxwlrjpdvHfdl7bFEmwa/4qb+gondJXQF83Z+GgAbQJ0K6 hCRbEckBTKhkS4tcD0+hhGrwf44XLAM3VOwEuXyRUjLWAjsnFbgY1weNvjk0hvERlTOS 9oWUenuJ/UcIq4W1e8Ctb2xDQ3xUG8dwbKKGgfTiTLJg5NSxQs4nPXPbs7kP4J6/FMat +A8m7TUS9SmbgrB3JXEG1Pg9ab6aNjndpptfl+L5RHR2EXwop6OP2TKHt5EqojpbNOUy Qz4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VTLXD5blFj23fdA7iuzbe11nPUGazX219WaDT87KGDQ=; b=WbLmMu+IY7LZubA8PAqLwG1q+qspWEsJ6rz1hax8q52WMP+FJZQZeDwBRmSaEqy+Hf XeYtACsuebXYCl7rWb+/HGbnI5D6xvxcUL/Uxb0JuBiZK5wtQij3+jb2vu958PUNA7/T qtAvbQvYjljNz4JVqc0de1uJ3P/gL/aKnw7cgqJDTxzIqAH9Rd/224/529YNMJ/6RLva evt0LRsGts3zM1xzqx7zXy/ptib5Kumom8XYVpNtFRhNEls8L9G4bI9Lp7b774jKlI48 wFwimLgE9FSuxnzyZ3xdXXwdoAyUleYw50C8iGnc1BryFbyGEw1TaOHViL+vGCdwniTA bQBg==
X-Gm-Message-State: ALoCoQlj13nyES/WoplZk6gfntELxIFf2TAVQC1MZVg+NXDY1kBiHLHrwW5///PP4vIl1pQIdQW8OGjHtAdflEYTrd+wm5dmtqw+elrnhP701jlHMh9YduOiGaOjJEYUtur7NggJ33A8dh7OcFdU8DqKxi46ZQu27iagW6v2bmFiHS7HntH3N5UCez5AF27hnPdvLpHX/MUe
MIME-Version: 1.0
X-Received: by 10.220.42.212 with SMTP id t20mr352402vce.45.1384449744940; Thu, 14 Nov 2013 09:22:24 -0800 (PST)
Received: by 10.52.111.230 with HTTP; Thu, 14 Nov 2013 09:22:24 -0800 (PST)
In-Reply-To: <FE61FDF5-1A84-49FE-AF85-463317EF0BDC@verisign.com>
References: <5284EE10.5020809@knipp.de> <FE61FDF5-1A84-49FE-AF85-463317EF0BDC@verisign.com>
Date: Thu, 14 Nov 2013 12:22:24 -0500
Message-ID: <CAAHh_-L2Zopu=LygHbUzgHhWs9N3i8tfWLif2yJraxbYCF-JGg@mail.gmail.com>
From: Seth Goldman <sethamin@google.com>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Content-Type: multipart/alternative; boundary=047d7b3a886041cdea04eb2653e3
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:22:26 -0000

Agreed, but at what level? The spec is unclear on this point. We have
interpreted the replace semantics to act on the "postalInfo" element, but
you could plausibly make an argument for replacing at lower level elements
(e.g. "addr" or "name" elements).

Regardless, I don't think the semantics you are seeing make any sense. It
might be technically spec compliant, but it's not very useful.


On Thu, Nov 14, 2013 at 12:00 PM, Hollenbeck, Scott <
shollenbeck@verisign.com> wrote:

> 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 mailing list
> provreg@ietf.org
> https://www.ietf.org/mailman/listinfo/provreg
>