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

From: Klaus Malorny <[email-masked]>
Date: Thu, 14 Nov 2013 16:36:48 +0100

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 14 Nov 2013 17:00:58 +0000

A change implies "replace all", Klaus.

Scott

> On Nov 14, 2013, at 10:38 AM, "Klaus Malorny" <[email-masked]> 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.
> 
> what shall be the outcome? The registry in question only replaces the first street line, retaining the second line:
> 
> 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-masked]
> https://www.ietf.org/mailman/listinfo/provreg

---

From: Seth Goldman <[email-masked]>
Date: Thu, 14 Nov 2013 12:22:24 -0500

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-masked]> wrote:

> > 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.
> >
> > what shall be the outcome? The registry in question only replaces the
> first street line, retaining the second line:
> >
> > 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.
> >

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 14 Nov 2013 18:48:48 +0000

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

Scott

> On Nov 14, 2013, at 10:38 AM, "Klaus Malorny" <[email-masked]<mailto:[email-masked]>> wrote:
>
>
> Hi all,
>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
provreg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/provreg

---

From: 齐超 <[email-masked]>
Date: Fri, 15 Nov 2013 13:33:44 +0800

Hello, Klaus,

I think it is necessary to come to a conclusion what is meaning of  label <contact:street> :
1,   two <street> is alternative,  e.g.
   C:            <contact:street>one address</contact:street>
   C:            <contact:street>another address</contact:street>
   C:            <contact:city>Dulles</contact:city>
   C:            <contact:sp>VA</contact:sp>
   C:            <contact:pc>20166-6503</contact:pc>
   C:            <contact:cc>US</contact:cc>  
2,   two <street>  is supposed to be composed to a complete address, e.g.
   C:            <contact:street>high level of address</contact:street>
   C:            <contact:street>low level of address</contact:street>
   C:            <contact:city>Dulles</contact:city>
   C:            <contact:sp>VA</contact:sp>
   C:            <contact:pc>20166-6503</contact:pc>
   C:            <contact:cc>US</contact:cc>

for 1, replacing one is acceptable.

for 2, replacing all is reasonable.

The RFC5733 example is :
   C:            <contact:addr>
   C:              <contact:street>124 Example Dr.</contact:street>
   C:              <contact:street>Suite 200</contact:street>
   C:              <contact:city>Dulles</contact:city>
   C:              <contact:sp>VA</contact:sp>
   C:              <contact:pc>20166-6503</contact:pc>
   C:              <contact:cc>US</contact:cc>
   C:            </contact:addr>

Two streets 'Suite 200' and '124 Example Dr.' is not obvious for me...  Can anybody explain it?

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 15 Nov 2013 10:01:28 +0100

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:chg>
</contact:update>

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

Regards,

Klaus

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 15 Nov 2013 10:16:11 +0100

On 15.11.2013 03:48, 齐超 wrote:
> 1, two <street> is alternative
>
> 2, two <street>  compose to a complete address
>
> for 1, replacing one is reasonable
> Two streets 'Suite 200' and '124 Example Dr.' is not distinct for me...

Hi 齐超,

I think it is clearly the second case. If these would be alternative addresses, 
then it would probably not be sufficient just to specify different streets. The 
locations could be in different urban districts (maybe causing different postal 
codes) or even different cities, states/provinces and countries. There are 
multiple streets to give room for more specific addresses, for example for large 
business buildings hosting a lot of companies, to specify departmental 
information in large companies or to allow different addressing schemes -- the 
western scheme of street names and house numbers are not necessarily applied 
world-wide.

Regards,

Klaus

---

From: 齐超 <[email-masked]>
Date: Fri, 15 Nov 2013 17:48:55 +0800

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

Hi Scot, Seth,

Regards,

Klaus

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 15 Nov 2013 11:46:54 +0000

> -----Original Message-----
> From: Klaus Malorny [mailto:[email-masked]]
> Sent: Friday, November 15, 2013 4:01 AM
> To: Hollenbeck, Scott; Seth Goldman
> Cc: IETF Provreg Mailing List

Go back to what I was trying to say yesterday: <chg> means "replace existing with new". So yes, it would change the international postal info to "empty".

> modify the postal info so that it *solely* contains the organization

Assuming all other schema requirements are met, yes.

Scott

---

From: Seth Goldman <[email-masked]>
Date: Fri, 15 Nov 2013 07:19:56 -0500

On Fri, Nov 15, 2013 at 6:46 AM, Hollenbeck, Scott <[email-masked]
> wrote:

> Go back to what I was trying to say yesterday: <chg> means "replace
> existing with new". So yes, it would change the international postal info
> to "empty".
>

I believe Klaus's point is that under this interpretation, the schema
allows you to update a postalInfo to a version that would not be allowed in
a create.

I still think your interpretation of the replace semantics is correct. But
the schema is inconsistent, so it's understandable to interpret it
otherwise.

---

From: James Mitchell <[email-masked]>
Date: Fri, 15 Nov 2013 12:43:38 +0000

Seth et al,

The info response would be invalid for contacts having a <postalInfo> with only an <org>. IMO the correct interpretation is that the command changes/modifies only the elements specified, however I’m not sure how one would interpret <chg><postalInfo type="int"><addr><street>A lane</street></addr></postalInfo></chg> - replace the “first” street element or all street elements?

FYI, for backwards compatibility our implementation performs a remove/replace for the direct children of the <chg> element only. The following examples hopefully illustrate the behaviour.

<chg><postalInfo type="loc"/><chg> -> remove the localised postal info
<chg><postalInfo type="int"><org>ACME</org></postalInfo><chg> -> fail, missing required values
<chg><postalInfo type="int"><name>ACME</name><addr><city>Melbourne</city><cc>AU</cc></addr></postalInfo><chg> -> success, previous int postal info replaced

Regards,
James Mitchell
Software Product Manager / ARI Registry Services

From: Seth Goldman <[email-masked]<mailto:[email-masked]>>
Date: Friday, 15 November 2013 11:19 pm
To: "Hollenbeck, Scott" <[email-masked]<mailto:[email-masked]>>
Cc: IETF Provreg Mailing List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [provreg] RFC 5733: street changes with contact:update

On Fri, Nov 15, 2013 at 6:46 AM, Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:
> From: Klaus Malorny [mailto:[email-masked]<mailto:[email-masked]>]

I believe Klaus's point is that under this interpretation, the schema allows you to update a postalInfo to a version that would not be allowed in a create.

I still think your interpretation of the replace semantics is correct. But the schema is inconsistent, so it's understandable to interpret it otherwise.

Scott

---

From: "Gould, James" <[email-masked]>
Date: Fri, 15 Nov 2013 14:04:11 +0000

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
     *   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.
     *   All sub-elements of the <contact:postalInfo> with type would be replaced including the two streets to one street example.
  2.  <contact:voice> to replace the voice
  3.  <contact:fax> to replace the fax
  4.  <contact:email> to replace the email
  5.  <contact:authInfo> to replace the authorization information
  6.  <contact:disclose> to replace the disclosure.

The questions are focused on <contact:postalInfo> since it's a complex entity with one to two instances ("int" or "loc").  I view the concept of change as being a replace of the instance whether it's a complex or simple instance.

--

JG

James Gould
Principal Software Engineer
[email-masked]

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

From: James Mitchell <[email-masked]<mailto:[email-masked]>>
Date: Friday, November 15, 2013 7:43 AM
To: Seth Goldman <[email-masked]<mailto:[email-masked]>>, "Hollenbeck, Scott" <[email-masked]<mailto:[email-masked]>>
Cc: EPP Provreg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [provreg] RFC 5733: street changes with contact:update

Seth et al,

Regards,
James Mitchell

Scott

---

From: Klaus Malorny <[email-masked]>
Date: Mon, 18 Nov 2013 12:52:21 +0100

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