Global Proprietary Messages

I propose to ban the use of the 0xEFFF PGN - the "Global Proprietary" message.

Frankly, when we wrote this section years ago, it never occured to any of us that anyone would think of sending a *proprietary* message to *everyone*! The idea is vaguely abhorrent to the concept of proprietary messages. The dangers are obvious - if two different nodes are using the same technique, they had better be using the same method of identifying the contents. But RV-C does not have a suitable identification method, as RV-C doesn't attach any real significance to the source address.

To my knowledge no RV-C supplier is using 0xEFFF. But it seems that in the J1939 world it is becoming commonplace. It seems for some designers this is their automatic fallback when they can't find the PGN they need in the book.

This has three negative effects.
- It puts any network in danger when two vendors use the same technique. In the SAE world this is mitigated by the fact that J1939 networks are usually pretty tightly engineered for high-volume production. RV-C has to support aftermarket and more loosely engineered products where conflicts are much more likely.
- It diminishes the incentive to submit new ideas to the committee. The growth of J1939 has been retarded in some areas because key vendors have chosen to continue using this method instead of subjecting their ideas to the scrutiny of the SAE.
- It creates a closed "network-within-the-network", which is offensive to the entire RV-C concept. Proprietary messages are intended for configuration and very product-specific features, not for general operation.

Fortunately, I know of no RV-C vendor using this technique, so this should have no immediate impact on current products.

AttachmentSize
Global Proprietary Messages.doc6.5 KB

We're on-board with this

We're on-board with this change and see it as beneficial to those it may touch in the future.