ACN Revisions to Review By August 23, 2010

BSR E1.17 - 201x, Entertainment Technology - Architecture for Control Networks, has been posted for review. The draft standard is a suite of documents that revise sections of the existing ANSI E1.17 - 2006. The revisions include changes to the Device Description Language, the Session Data Transport protocol, the Device Management Protocol, and to various EPIs.The revisions are being done to correct errors and to add additional functionality to the standard. The official ANSI review runs from July 9 through August 23, but the documents are available now, and public review responses will be accepted if they are early—but not if they are late. The review is over when August 24 starts. Responses must be submitted before then to be considered.

Philip Nye, of UK-based Engineering Arts, and a member of the ACN Task Group, has provided some insight into the standard and suggested revisions:

In a standard of the breadth of ACN, there are bound to be errors and inconsistencies. Experience in implementing and using it over the four years since it was published has shown up a number of deficiencies which the Task
Group have looked into in great depth. There are a number of broad categories among the proposed revisions:

- Bugs: The original documents contain errors which if followed to the letter, either do not make sense, or lead to non-functioning or buggy implementations;

- Contradictions: Despite ESTA's best efforts there are a few places where the standard contradicts itself—usually in an indirect way;

- Ambiguities: There are places where the wording is open to misinterpretation, which can lead to outright failure or to interoperability problems;

- Improvements: Whilst resisting making a lot of changes, the Task Group is proposing a number of changes which we believe considerably improve the performance, ease of implementation and usability of ACN in exchange for zero or modest cost in modifications to existing implementations. Most of these are simplifications or generalisations. The biggest set of changes of this nature come in DDL which has some "features" which are needed but are extremely awkward to use in the original version.

So, are all these important? As a member of the task group, I am bound to say yes. It is vital to address the bugs and contradictions and eliminating ambiguities must be good. As for the improvements —nearly all of these have been implemented by Task Group members experimentally and we have satisfied ourselves that they are truly improvements.

Do I think that the revision should be accepted? Yes —but not blindly. I would rather see a revision which gets it right than rush this through and have to revise again almost immediately. The revisions themselves are of sufficient volume that they may contain their own errors or inconsistencies, a reviewer simply pointing out spelling and punctuation errors, or inconsistencies in cross referencing is very useful. Beyond that, there is the question of whether there are errors we have missed, of whether the changes really solve the original errors or are the best solutions, and of whether the proposed improvements are necessary or sufficient— which is probably a matter of opinion. The more people that read the review documents with any of these points in mind, the better.

The review documents which are downloadable from ESTA contain an "informative" listing which outlines, document by document, each problem the revision seeks to address and the proposed solution. For anyone wanting to assess the revision at a technical level, this is a good place to start.

In terms of further development of ACN, the long time in getting these revisions to public review and then on to standardization, has created a log-jam in a number of extension standards which rely on the revised ACN. This is particularly true for any extension which relies on DDL and should follow the revised version.

This does not mean that these extensions cannot be examined, implemented and tested using drafts of the revised documents, but they cannot be finalized. Application of ACN to specific issues is the main thrust of these efforts which includes MIDI, Time Code, Inter console communication and distributed storage of system configuration. Meanwhile developments elsewhere in Ethernet Audio Video Bridging (EVB) are likely to throw down new challenges across the industry for which ACN can be an ideal solution in the professional network arena.

Related stories:

ETC Applauds ANSI Acceptance of ACN

Control Protocols On The Go