[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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-


Home | Date list | Subject list