--On Friday, 19 September, 2008 13:52 +0200 Stephane Bortzmeyer
<bortzmeyer@xxxxxx> wrote:
>> It's no use to me if someone sells a product that claims to
>> support "SMTP"
>
> That's trademark protection and it was never considered
> seriously by the IPR WG. This WG, instead, tried to prevent
> people from reusing RFC but did absolutely nothing to guard
> against an attack such as the one you describe. (To create a
> rogue "SMTP" protocol, you do not need to modify a RFC.)
Actually, it isn't trademark protection, at least in any of the
usual senses.
But it may be fraud, or at least misrepresentation of the
product. And that is actually part of the point. Independent
of any forks in code, etc., (and I completely agree with Ted
Hardie's comments on that subject earlier today), if it is well
understood that "SMTP" is a designator for a specific IETF
protocol, then it is desirable for that specification to be
sufficiently stable that those who buy can react if the
assertion is not true. Of course, selling a product that
claims to conform to RFC 2821 is a somewhat stronger statement
than "claims to conform to SMTP" is "supports SMTP", but the
issues are very much the same.
Standards, as distinct from particular implementations and their
variations, actually serve two purposes. We have been
discussing one, which, in the IETF case, is having
specifications that are sufficiently precise and stable that
interoperability among independent implementations is possible
and, indeed, likely. Ted's summary of that situation is as
good, or better, than anything I could say. But the other is
precisely to permit people to make "supports A" or "conforms to
B" claims in a reasonable way and to make those claims testable
(not by the IETF; we have chosen, I think wisely, to avoid the
certification business) and those tests to be enforceable by
contracts, public ridicule for deviations, etc.
Forks in documents, or other sorts of local variations, create
confusion in the marketplace and uncertainties about what claims
are being made. They are, if anything, even more problematic
than the issues that Ted cites.
Of course, if someone wanted to say "this supports much of SMTP,
but reflects the author's own theories about some of the
protocol", there would be, I hope, no attempt by the IETF to
prevent that. The marketplace would do whatever it chose to do
with such a package.
Finally, please remember that there is nothing about copyright
protection on the text of the specification that prevents an
implementation of that specification. There might be exceptions
if our specifications were formal and systematic enough to
permit automatic translation of the specifications into code,
but, fortunately or unfortunately, that is not an issue. The
other exception, of course, occurs when the specification
contains code, pseudo-code, or tables that have to be copied
literally... and that was exactly why the IPR WG decided to
separate those cases from the text. But, as to the notion that
one can't realistically implement IETF specifications without
being able to change them and claim that one's changed version
is just an improved, equally-valid, version of the same thing, I
don't see how we can encourage that and still claim to be in the
business of making standards.
john
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf