To:
"janusz" <janusz@ca.afilias.info>
Cc:
<ietf-provreg@cafax.se>
From:
"Hollenbeck, Scott" <shollenbeck@verisign.com>
Date:
Tue, 11 Jul 2006 07:15:39 -0400
Content-class:
urn:content-classes:message
Sender:
owner-ietf-provreg@cafax.se
Thread-Index:
AcakXlFrWrGSdY4QRreuRvVI0Q0ErQAfLduQ
Thread-Topic:
extensding EPP <update> command for contact
Subject:
[ietf-provreg] RE: extensding EPP <update> command for contact
> -----Original Message----- > From: janusz [mailto:janusz@ca.afilias.info] > Sent: Monday, July 10, 2006 4:23 PM > To: Hollenbeck, Scott > Cc: ietf-provreg@cafax.se > Subject: extensding EPP <update> command for contact > > 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). This issue was discussed on the list a while back and has been fixed in the recently-expired -bis documents. This is how the new text reads: At least one <contact:add>, <contact:rem>, or <contact:chg> element MUST be provided if the command is not being extended. All of these elements MAY be omitted if an <update> extension is present. -Scott-