Re: RFC 5733: street changes with contact:update

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

From: Seth Goldman [mailto:[email protected]]
Sent: Thursday, November 14, 2013 12:22 PM
To: Hollenbeck, Scott
Cc: Klaus Malorny; IETF Provreg Mailing List
Subject: Re: [provreg] RFC 5733: street changes with contact:update

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 <[email protected]<mailto:[email protected]>> wrote:
A change implies "replace all", Klaus.

Scott

> On Nov 14, 2013, at 10:38 AM, "Klaus Malorny" <[email protected]<mailto:[email protected]>> 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
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/provreg
_______________________________________________
provreg mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/provreg

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg