Re: Anyone working on 4310-bis?
James Gould <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <C70DCE33.3575A%[email protected]> |
Klaus,
Your proposal will work with one small fix of replacing </sequence> in
remType to </choice>. This will be backward compatible, will address the
issue of identifying the DS record to remove, and will support adding and
removing more than one DS record in the same command. I like that the chg
still behaves like a replace, which again is backward compatible. The only
difference is that all four elements need to be provided (keyTag, alg,
digestType, digest) with a rem, which I don¹t believe should be a big issue.
Does anyone see an issue with having to specify either the keyTag or all
four elements on a rem? The following is the schema elements with the small
fix that I tested through with various use cases successfully.
<complexType name="updateType"> <choice> <element
name="chg" type="secDNS:dsType"/> <sequence> <element
name="add" type="secDNS:dsType" minOccurs="0"/> <element
name="rem" type="secDNS:remType" minOccurs="0"/> </sequence>
</choice> <attribute name="urgent" type="boolean" default="false"/>
</complexType> <complexType name="remType"> <choice
maxOccurs="unbounded"> <element name="keyTag"
type="unsignedShort"/> <element name="dsData"
type="secDNS:dsDataType"/> </choice> </complexType>
The following tests worked and passed schema validation:
* Passing a single add, chg, or rem with the rem containing just the keyTag.
This is the backward compatible tests.
* Passing multiple dsData elements for both the add and rem elements
* Passing multiple keyTag or dsData elements with the rem element
--
JG
-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email protected]
Direct: 703.948.3271
Mobile: 703.628.7063
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166
Notice to Recipient: This e-mail contains confidential, proprietary and/or
Registry Sensitive information intended solely for the recipient and, thus
may not be retransmitted, reproduced or disclosed without the prior written
consent of VeriSign Naming and Directory Services. If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy. Thank you.
From: Klaus Malorny <[email protected]>
Date: Tue, 27 Oct 2009 19:38:02 -0400
To: James Gould <[email protected]>
Cc: Howard Eland <[email protected]>, EPP Provreg <[email protected]>
Subject: Re: [ietf-provreg] Anyone working on 4310-bis?
On 2009-10-27 22:31, James Gould wrote:
> [...]
>
> Updated XML schema:
> <complexType name="remKeyType">
> <simpleContent>
> <extension base="unsignedShort">
> <attribute name="alg" type="unsignedByte"/>
> <attribute name="digestType" type="unsignedByte"/>
> <attribute name="digest" type="hexBinary"/>
> </extension>
> </simpleContent>
> </complexType>
>
> <complexType name="remType">
> <sequence>
> <element name="keyTag" type="secDNS:remKeyType"
> maxOccurs="unbounded"/>
> </sequence>
> </complexType>
>
> [...]
Hi James,
instead of adding attributes, one could declare the content of the <rem>
element
to be a choice between the <keyTag> element and the <dsData> element, with
unbounded repetition, e.g.
<complexType name="remType">
<choice maxOccurs="unbounded">
<element name="keyTag" type="unsignedShort"/>
<element name="dsData" type="secDNS:dsDataType"/>
</sequence>
</complexType>
Also, I propose a change to allow both <add> and <rem> to occur in the same
request, i.e. something like this (may be formally incorrect, haven't
checked
the syntax):
<complexType name="updateType">
<choice>
<element name="chg" type="secDNS:dsType"/>
<sequence>
<element name="add" type="secDNS:dsType" minOccurs="0"/>
<element name="rem" type="secDNS:remType" minOccurs="0"/>
</sequence>
</choice>
<attribute name="urgent" type="boolean" default="false"/>
</complexType>
Regards,
Klaus