Hi. I've pulled this out of Matti's note and made it Issue 9.
--On Thursday, 29 March, 2007 16:54 +0300 Matti Aarnio
<mea+ietf-smtp(_at_)nic(_dot_)funet(_dot_)fi> wrote:
...
Perhaps there should be a new Appendix that tabulates limits
in condensed manner making checking them simpler in style of
IEEE 802.* Conformance Pro Formas ?
It would list limits and references to main text for
rationales.
Somewhat in style of RFC 1123 "SMTP REQUIREMENTS SUMMARY"
table ? That table is more about "feature checklist" than
protocol parameter profile listing, but applying the idea.
I've leave it up to Tony as to whether this constitutes a
document reorganization. If it is not, this is likely to get
done a lot sooner if someone would supply a proposal in xml2rfc
form (but see below). If it has to wait on me and my current
queue, it would significant delay the document, not through lack
of interest but through lack of time. If it does constitute a
reorganization, this newly-assign issue presumably gets closed.
...
Also, a style issue is that when a chapter is defining more
than one thing, that chapter should have numbered sub-chapters.
It is far easier to point to somebody that "your filter is
violating expectations at 1.2.3.4.5 of rfc-12345" than ".. at
chapter 1.2.3 paragraphs 7 through 9 of rfc-12345"
I was thinking about that this morning. Let me see what can be
done. Your sending me (off-list) a list of sections that you
think particularly need the "subsection rather than list" or
"subsection rather than paragraph" treatment would help.
Is there any objection to this from the group if I can do it?
Or even parts of it?
One caution, however: xml2rfc, and the RFC format more
generally, are not particularly friendly to this idea. I'm not
aware of any practical way to create a list that is both
numbered and that uses hanging item titles. I don't believe
there is a way to number paragraphs other than as sections, and
sections require titles which, except for those now arranged as
lists, would be fairly cumbersome. I've never worked with the
indexes it can create so have no experience with whether we
could create an index that would cover the terms we would want
(see below).
For time availability and future updating reasons, going back to
any formatting arrangement other than xml2rfc is just not going
to happen.
Similarly, lacking the detailed parameter conformance checklist
means that one has to go through the main text, and to spot
there all small details in very lengthy chapters.
In principle, we could create an index. That would be a lot of
work too, but maybe less that creating, and agreeing on, a
definitive table or conformance checklist. It also has one
advantage: if we do a table or checklist, and leave something
out by accident, we are likely to invite trouble because the
table may become a substitute for the spec. An item
accidentally left out of an index would presumably not cause
that problem, no matter how much whining it caused.
john