I made the proposal for the optional "standard" attribute with the list message (https://mailarchive.ietf.org/arch/msg/regext/7E6X5xCdt3DhqL7p7CFupm9bAAY/?qid=e4f712bc8e70e4d0a458971928924651) on the thread with Pat Moroney. The description in the proposal was " Add a new optional “standard” boolean attribute to the <fee:command> element, with the default value of “0” (or “false”), that indicates whether the fees for the command and period matches the “standard” classification fees for the command and period.". To address your concern, how about revising the description to the following:
..., an OPTIONAL "standard" attribute with a default value of false (0) that indicates whether the fees for the command and period matches the "standard" classification fees (see section 3.7), ... In hindsight this attribute should have been exclusively included in the <fee:command> of the check response (XSD commandDataType instead of base commandType) since I believe it's only provided by the server, but that would require a schema change. The definition of the attribute may have to be moved as well to the check response command description. — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 4/13/18, 2:52 AM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: On Wed, Apr 11, 2018, at 22:24, internet-dra...@ietf.org wrote: > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-fees-11 I see that this includes some of my latest comments (but not all of them, for example required attributes still do not have use="required" in the schema, and I have not seen an explanation about that), so thanks for taking them into account. However I still think there is a big problem for the "standard" attribute. For me even this new version does not define it really. Where it appears it says now: The <fee:command> element(s) contain(s) a "name" attribute (see Section 3.1), an OPTIONAL "standard" attribute with a default value of false (0) (see section 3.7), an OPTIONAL "phase" attribute, and an OPTIONAL "subphase" attribute (see Section 3.8). The <fee:command> element(s) MAY have the following child elements: so it references the section 3.7, which is new. But the problem is that this section only speaks about classes and the <fee:class> element in responses. There is again nothing there about the "standard" attribute of a <fee:command> in requests. There is specifically a need to explain things in relation to last line of this section. What happens/What does it mean/Is it allowed or not when fee:class=standard but standard=false or when fee:class=premium but standard=true? Especially since both elements are optional. I believe that this lack of explanations can cause major interoperability problems, even more so because this attribute was added very late in the draft lifecycle. Maybe people in favor (I am not) of this attribute should chime in and provide some useful text to add in the specification. I do not think it can pass LC without this fixed. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
