I find this document a bit puzzling.
Obviously, the notion of "expectation" is not meant to be descriptive. No
one really expects implementors to meet all the "expectations", and often
they do not.
So the notion of "expectation" must be intended to be prescriptive, roughly
equivalent to "obligation". However, there does not seem to be any legal
obligation to do all the things the document lists. And it would be rather
far-fetched to claim that failing to follow a protocol specification is
immoral or unethical.
The document would be less puzzling if it gave up all talk of "expectations"
or obligations and simply said "if you want to maintain interoperability
with other implementations, here are things that would be wise to do". If
that's all that is really meant. Even so, it has the feel of the sort of
lecture that parents like to give their teenagers: "if you live in my house
you have to follow my rules". And it will have the same effect (i.e., no
effect).
I also think the document has a few serious mistakes.
For instance:
"Follow the protocol specification"
Well, that sounds harmless enough, but sometimes the protocol specification
has errors (sometimes of omission), and the errors are known to the
implementors. Are they supposed to implement the errors?
"Follow the standard" is ITU-T stuff, and leads to conformance testing; "do
what you have to do in order to interoperate" is much more in the IETF
spirit.
"IETF standards are voluntary standards. No one is required to
implement them. Implementation is a choice."
Sorry, most implementors are not volunteers, but are being paid to implement
the protocols. Often there is no real choice involved.
Or by "implementor", does the document mean "whoever is paying to have the
implementation done", rather than "whoever does the implementation"? In
that case, "the implementor" would often be a company. And the individuals
doing the implementation will do what is necessary to accomplish the
company's goals, even if this deviates from the advice given in this
document.
"An implementer should plan to maintain their
implementation. It is not sufficient to do an initial implementation
of the protocol. One needs to apply changes as they come out."
While this may be generally good advice for any computer programmer, it
obviously does not apply to individual implementors who move on to other
tasks or other companies. As for whether a company needs to maintain its
implementation in this way in any particular case, well, that depends on
business considerations.
There are also a few things that are not very clear.
"The Internet is composed of networks operated by a great variety of
organizations, with diverse goals and rules. By following the BCPs,
implementers, operators, and administrators are able to provide a
common experience when using the protocol, regardless of their point
of attachment to the Internet."
What does this even mean, "a common experience"? And what does that have to
do with BCPs? And what if a common experience is not desired? And what if
changes in technology or business conditions make the BCPs less relevant
(assuming they were ever relevant to being with)?
"Implementers are expected to follow the IANA registry practices
associated with the protocol, especially in the assignment of new
values. By following these practices, other implementations will
learn about new values and make the appropriate updates to handle
them properly."
This is a good example of the platitudinous nature of the document. There
are numerous reasons why IANA practices are not always followed in practice:
- An implementor might not know the proper IANA processes.
- An implementor might know the processes, but think they are too
cumbersome, when it's much easier just to define a constant in a header
file.
- If the registration policy is "standards action" or any other policy that
requires IETF or IESG review, codepoint allocation can become enmeshed in
politics and/or business rivalries. There are circumstances in which one
really has no other choice than to follow the rule that "it is better to
apologize later than to ask permission first".
It's not that useful to say "just follow the process" without saying
anything about the problems that prevent the process from being followed in
many cases.
So overall I'd say that this document is not worth publishing, but if it is
published it should be made clear that it is about "what you have to do to
maximize the chances of interoperability" than it is about "what you have to
agree to before you are allowed to implement".