To:
James Gould <jgould@verisign.com>
CC:
"Hollenbeck, Scott" <shollenbeck@verisign.com>, EPP Provreg <ietf-provreg@cafax.se>
From:
Klaus Malorny <Klaus.Malorny@knipp.de>
Date:
Fri, 12 Dec 2008 10:00:06 +0100
In-Reply-To:
<C5668CF6.2FBF1%jgould@verisign.com>
Sender:
owner-ietf-provreg@cafax.se
User-Agent:
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1b3pre) Gecko/20081210 Shredder/3.0b2pre
Subject:
Re: [ietf-provreg] DNSSEC EPP Extension (RFC 4310) Usability Question
On 12/11/2008 03:25 PM, James Gould wrote: > Klaus, > > Your two statements “The respective DNSSEC EPP Extension could handle > this in the same way, > i.e. a certain key tag may appear only in one of the three sections > within one > request, otherwise the request would fail” and “Although I don't think > there is a > need to update RFC 4310, I think such kind of constraints in the EPP specs > should be a little bit more relaxed to make it more flexible” are sort > of conflicting. > > RFC 4310 would have to be updated to allow for the use of add, rem, and > chg in a single command. The XML schema defined in the RFC will disallow > a combination of add, rem, and chg assuming the Registry has XML schema > validation enabled, which in our case we do. Do you see a need to change > the XML schema? > > -- > Hi James, as I am in favour of not increasing the protocol entropy without a real need(*), I would not update RFC 4310 just for this reason. This is not a limitation one cannot live with. If there would be a major overhaul of this RFC, one could consider to change the <choice> to a <sequence> though, as this is backward compatible. Regards, Klaus * We still struggle with various pre-EPP-1.0 and other strange EPP (-like) implementations.