‘Strong’ or ‘weak’ standards are about the difference between ‘explicit abstraction’ and ‘deferred abstraction’ (standards are abstractions, they just have a particular kind of usage).
For example:
Strength is about how much the standard defines then and there. If the standard defines all the possible values for such type-tags (hence, all meanings of the payloads), it is strong. The weakness is in leaving those parts open to external/future/unknown specification. It is somewhat like ‘strong’ and ‘weak’ typing.
It is not weak if some implementation is deferred. For example, a plugin API: it might send mouse events and receive pixel values, for a particular region of window. The actual values, how they are made, what they mean, is left free. But nothing in the standard depends on the meaning of the free values. So the abstraction is clearly and completely defined.
Weak standards are problematic in use. The more optional, deferred, parts, the more difficult it becomes to write any single piece of software to usefully handle any particular piece of data that might showup.
Weak standards seem almost entirely a design ailment. They look like they are doing something, but are actually doing practically nothing. They are an example of non-design design. It has the rationale of designing for the future, i.e. the unknown, so it seems to be worthwhile. But design, in the essence of what it does, can only produce for the known – design for the unknown is a contradiction. A weak standard, as far as it is weak, is not really a standard at all, because it isn't really standardising anything.