To:
"'iesg@ietf.org'" <iesg@ietf.org>
Cc:
"'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
From:
"Hollenbeck, Scott" <shollenbeck@verisign.com>
Date:
Fri, 8 Mar 2002 21:45:23 -0500
Sender:
owner-ietf-provreg@cafax.se
Subject:
Some EPP Last Call Comments
After the provreg WG's EPP documents finished WG last call, but before the IESG's last call was issued, I received word of a few defects that should be fixed and also a few requests for additions. Here are links to the comments made publicly, and text for those I received privately: 1. Category: Fix http://www.cafax.se/ietf-provreg/maillist/2002-02/msg00032.html In the epp-06 schema, this: <element name="clTRID" type="epp:trIDStatusType" minOccurs="0"/> should be changed to this: <element name="clTRID" type="epp:trIDStatusType" minOccurs="0" maxOccurs="unbounded"/> This will allow more than one element as described in the text. 2. Category: Fix http://www.cafax.se/ietf-provreg/maillist/2002-03/msg00004.html In the domain-04 schema, this element in the <info> response: <element name="registrant" type="domain:contactType" minOccurs="0"/> should be changed to this: <element name="registrant" type="eppcom:clIDType" minOccurs="0"/> This will make the data type correct in the <info> response. 3. Category: Requested Additions http://www.cafax.se/ietf-provreg/maillist/2002-03/msg00006.html A request to add an additional response code, additional statuses, and explanatory text. 4. Category: Fix and Requested Addition http://www.cafax.se/ietf-provreg/maillist/2002-03/msg00013.html A fix to increase the length of the contact-04 postal code field from 10 to 16 characters, and a request to add an OPTIONAL field to better help explain server error conditions. 5. Category: Documentation I received a private suggestion to number document paragraphs that describe elements in addition to indenting them to better help identify parent-child relationships. 6. Category: Requested Addition Patrik suggested a modification to the object <authInfo> structure such that authentication mechanisms other than passwords could be defined in the future without requiring change to an existing schema. This can be done by changing the <authInfo> data types slightly to accommodate namespace extensions. -Scott-