> 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.