Compliance to a protocol description? (wasRE: I'm struggling with 2219 language again)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Maybe part of the job of a working group should be to both/either produce or
approve a reference implementation and/or a test for "interoperability"?  I
always thought a spec should include an acceptance test.  Contracts often
do.

If a company submits code that becomes reference code for interoperability
tests, that code is automatically interoperable and "certified".  That might
mean more companies would spend money to produce working code.  It might
mean that more working code gets submitted earlier, as the earliest approved
code would tend to become the reference.  By code, I don't mean source,
necessarily.

Then there would be a more objective test for compliance and less dependence
on capitalization and the description.

++++++++++++++++++++++++++++++++

  Meh. I know the IETF has a thing about these terms, and insofar as they
can
  lead to the use of and/or overreliance on compliance testing rather than
  interoperability testing, I agree with that sentiment.

  OTOH, when it comes to actually, you know, writing code, this entire
attitude
  is IMNSHO more than a little precious. Maybe I've missed them, but in my
  experience our avoidance of these terms has not resulted in the magical
  creation of a widely available perfect reference implementation that
allows me
  to check interoperability. In fact in a lot of cases when I write code I
have
  absolutely nothing to test against - and this is often true even when I'm
  implementing a standard that's been around for many years.

				Ned




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]