On Sun, Dec 14, 2008 at 6:20 PM, Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
is there a compliance test suite?
Not as far as I know. I certainly have no plans to write one or subject our
implementation to any that someone else develops. I doubt if anyone else does
either.
The IETF isn't big on compliance test suites as a rule - the overarching goal
here is interoperability, not compliance.
however, AFACT the charter of this group does include testing
And this IMNSHO is a very good thing. in the past I've worked on software,
notably an X.400 implementation, governed by standards that emphasize
compliance testing. What I've observed is that after passing multiple very
extensive compliance test suites, the software still failed to interoperate
worth a damn and required all sorts of tweaks before it could.
there is no silver interoperability bullet :-)
all the stuff i help to develop is agile FOSS (TDD and BDD). automated
tests will need to be developed so it's just a question of whether the
tests exist already and can be shared and reused between
implementations. the unit tests themselves are only really effectively
portable between the moderns (.NET, java, python) but it's the
verified example mappings which will take the time.
As a result of this and several other experiences I must confess to
considerable cynicism that compliance testing represents a path to
interoperability. In my experience it does not, and has been for the most part
a colossal waste of time.
automated testing has come a very long way in the last decade but i
understand your perspective
IMO it is a method (but not the only one) of producing reliable
relatively bug free software. i think this is a reasonable
pre-requisite for good interoperability. a good suite should aim to
reduce the numbers of poor implementations which claim compatibility
rather than try to ensure that good implementations interoperate
perfectly.
<snip>
is there a (standard) copy of the schema available under a reasonable
(MIT, BSD) license?
Well, now you't hit on a sore point. My understanding is that the intent is
for
the copyright on RFCs to allow essentially unrestricted reuse of all the
material RFCs contains: Text, programs, schemata, etc. But the actual
copyright
that's applied falls short of this.
yes
(this usually means having to create clean room implementation of
schema from descriptions in the RFC)
Attempts are ongoing to fix this, culminating in some new copyright
boilerplate
that apparently will be required for use in another couple of days even though
the update to xml2rfc, the primary tool a lot of folks use to produce Internet
Drafts , has not been released yet. (And yes, I'm aware there's a beta that
supports it. Just what I need: More beta software in my life.)
:-)
Will the new boilerplate give you the permission you need to simply use the
schema from the specificaiton. Hopefully the answer to that is yes. But IANAL,
and there are already more than enough engineers around here playing at being
laywers. We don't need any more, so I'm taking no position on any of this
stuff.
(apache is lucky enough to have friendly lawyers so this isn't such an
issue for me)
The bottom line, such as it is, is that there's effectively no leeway in the
copyright boilerplate you have to use if you want your stuff published as an
RFC. So I, and I suspect a lot of others, simply go with the flow and use
whatever we're told we have to use. If this is problematic for you, the place
to take that up is on the IPR WG list. It is not within our charter here to
consider such matters in any case.
does the IEFT require copyright assignment?
- robert