On Fri, Apr 13, 2018, at 15:09, Gould, James wrote: > 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.
Yes, but that was not included in the document and noone replied to your request for thoughts. > 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), ... Maybe it is just me, but I still think that for someone new (or even not so new) this is confusing. If client stays standard=false does that mean that the reply can not have class=standard? On the opposite with standard=true, should? must? the reply have a class=standard reply? This all seems under specified to me. > 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. The fact that there is a need to change the schema at the last time clearly shows to me that something is half-baked and should not be shipped as is. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
