Subject: Re: [ietf-provreg] extensding EPP <update> command for contact

From: Klaus Malorny <[email-masked]>
Date: Mon, 10 Jul 2006 22:58:11 +0200

janusz wrote:
> Scott,
> [...]
> The same section in domain object mapping document contains a provision 
> for EPP domain <update> commands without any element to modify.
> [...]
 >
> Janusz Sienkiewicz
> 

While it is possible in the domain mapping (RFC 3731) to legally create an 
update command that does nothing, there is still a sentence that requires 
unnecessary XML (page 27, third paragraph from bottom):

    At least one <domain:add>, <domain:rem>, or <domain:chg> element MUST
    be provided.

So, RFC 3731 should be included in your considerations. When we discovered this 
problem last year we decided to simply ignore this MUST in our server 
implementation and to do not reject the command if such a condition occurs. I 
don't see a reason for the prohibition of an "empty" update anyway.

Regards,

Klaus

___________________________________________________________________________
      |       |
      | knipp |                   Knipp  Medien und Kommunikation GmbH
       -------                           Technologiepark
                                         Martin-Schmeißer-Weg 9
      Dipl. Inf. Klaus Malorny           44227 Dortmund
      [email-masked]             Tel. +49 231 9703 0

---

From: janusz <[email-masked]>
Date: Mon, 10 Jul 2006 16:22:40 -0400

Scott,
according to the wording of section 3.2.5 in RFC 3733 EPP contact 
<update> command has to contain at least one element to modify. The fact 
can be very inconvenient for potential EPP extensions of the command. 
The same section in domain object mapping document contains a provision 
for EPP domain <update> commands without any element to modify. 
To make EPP extension of contact <update> command reasonably convenient 
and to restore protocol symmetry the wording of the section 3.2.5 in RFC 
3733 should be modified to allow EPP contact <update> commands that do 
not contain any element to modify.

Similar problem exists for host object mapping (RFC 3732, section 3.2.5).

Janusz Sienkiewicz