|
> The draft-lourdelet document defines a new data type. 8-bit tag, > followed by 32-bit integer. While this is arguably better than the RFC > 2868 form, it still is a new data type. And the document discourages > new data types. OK. So the issue is not the use of RFC 2868 tags. > Maybe the document needs to say: > > In order to meet these objectives, this document needs to cover not > only the science of attribute design, but also the art. As a result, > in addition to covering the most frequently encountered issues, this > document attempts to provide some of the considerations motivating > the guidelines. Reviewers are expected to weigh the cost and > benefits of following or ignoring the guidelines, as nearly all > suggestions here are of the form "SHOULD" or "SHOULD NOT". The > intent is for the guidelines to help authors create better documents. > This intent means that reviewers can choose to ignore some of the > recommendations herein. When this is done, their review MUST be > accompanied by an explanation as to why the guidelines were not > followed, and why following the guidelines would have resulted in > a worse architecture. Personally, I don't think this text is necessary; RFC 2119 defines the meaning of SHOULD. > > Perhaps the Design Guidelilnes document should be more > > clear about exactly what the flaws were in the RFC 2868 scheme that the > > SHOULD NOT applies to. > > Or, it could say that the tagging mechanism MAY be used when none of > the above limitations apply. Or, it might describe how a single octet tagging scheme might avoid the problems of RFC 2868. |