[rfc-i] Numbering and counting things (was: Re: New Version Notification for draft-flanagan-plaintext-00.txt)

Phillip Hallam-Baker phill at hallambaker.com
Wed Jun 25 11:39:13 PDT 2014


On Wed, Jun 25, 2014 at 12:02 PM, Ted Lemon <mellon at fugue.com> wrote:

> On Jun 25, 2014, at 7:53 AM, John C Klensin <john-ietf at jck.com> wrote:
> >> When we're writing a spec, IMO the text ought to be normative,
> >> and the  text alone ought to be sufficient (even if tedious).
> >
> > And that, in a sentence, is one of two major problems with
> > declaring that the marked-up (xml2rfc) version is normative and
> > that none of the normally-human-readable presentation versions
> > are.
>
> We have to trust (and verify) that the tools produce human-readable output
> that accurately represents what is in the actual XML.   We've discussed how
> to do this at length—it's not a new question to us.   Indeed, the IESG had
> a discussion with Heather present on the topic of whether or not diagrams
> are normative, because we had the same concern.   What consensus arose,
> which was not terribly solid, is that we can't assume that the diagrams are
> not normative, and that we ought to address the accessibility issues that
> are implicit in that statement.


Normative might have great significance in a lawsuit where someone claimed
that a protocol was not correctly implemented. But we haven't seen that
scenario very often if at all it is a 5% concern if at all.

The much more common problem is that the engineer either misread the spec
or didn't read the spec at all because the secondary sources are much more
accessible.

Good typography and clear diagrams make it much more likely the spec will
be read and followed correctly. That is the 95% concern.


Another problem with the current situation is that it encourages a
situation where hard design issues slide by a WG. I did warn the DKIM
working group that their understanding of policy was bjorked and so was
their versioning system.

Both issues might have been addressed if there had been a state diagram in
the doc setting out the intended decision algorithm. Instead the use cases
were considered separately and separate, incompatible decision algorithms
proposed for each. "oh you can solve that by doing X, and that by doing
not-X'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20140625/43ddd861/attachment.html>


More information about the rfc-interest mailing list