It has been pointed out to me that the second sentence is unintentionally ambiguous. The point I was making is that when the spec has the examples included it is much more likely to result in successful interop than the case where the spec has no examples. Although I generated the initial examples the ones in the final spec were generated by Tommy Lindberg after I moved on to another project. > -----Original Message----- > From: Hallam-Baker, Phillip [mailto:pbaker@xxxxxxxxxxxx] > Sent: Wednesday, July 26, 2006 12:17 PM > To: Hadmut Danisch; ietf@xxxxxxxx > Cc: rfc-editor@xxxxxxxxxxxxxx > Subject: RE: Mandatory numeric examples in crypto-RFCs? > > I provided these examples in XKMS and the general feedback on > doing so was very positive. We found that implementations > were much more likely to interop having been written from the > spec alone than without the examples. It also helped identify > ambiguities in the specification as people reported > ambiguities in the text where they resorted to the examples > for checking. > > > -----Original Message----- > > From: Hadmut Danisch [mailto:hadmut@xxxxxxxxxx] > > Sent: Wednesday, July 26, 2006 10:41 AM > > To: ietf@xxxxxxxx > > Cc: rfc-editor@xxxxxxxxxxxxxx > > Subject: Mandatory numeric examples in crypto-RFCs? > > > > Hi, > > > > I am currently debugging some ISAKMP problems and thus > using RFCs like > > 2085, 2412, etc. about cryptographic algorithms and data formats. > > > > > > Such RFCs are sometimes a little bit ambiguous or difficult to read > > since details are spread around the paper. When implementing such > > algorithms or data parsers, you don't know whether the > implementation > > is correct without a test case, e.g. feeding in some examples and > > check whether the result is what is expected. > > > > > > I'd therefore propose that every RFC dealing with crypto > algorithms or > > data formats has to have a mandatory appendix section with > examples to > > be used as a test case. (Every I-Draft should have.) > > > > E.g. when describing key agreements precise examples of the random > > numbers and secrets, byte sequences of example messages, and the > > results (signatures, keys,...) should be given allowing to > do a simple > > check of any implementation to see, whether the > implementation works > > in principle, and does not have such common bugs like wrong > padding, > > byte order problems etc. > > > > > > > > regards > > Hadmut > > > > > > _______________________________________________ > > Ietf mailing list > > Ietf@xxxxxxxx > > https://www1.ietf.org/mailman/listinfo/ietf > > > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf