I think Peter's right. A responder should be able to handle both.
This could make things difficult for the controller. If the controller issues two issue back-to-back PIDs with different Parameter Data, it may be ambiguous what the response contains.
Looking at the PID list in E1.20, there are 6 PIDs that are likely to grow enough that they require an ACK_OVERFLOW
- PROXIED_DEVICES
- STATUS_MESSAGES
- SUPPORTED_PARAMETERS
- LANGUAGE_CAPABILITIES
- SLOT_INFO
- DEFAULT_SLOT_VALUE
The biggest potential culprit here is STATUS_MESSAGES (The others all have a PDL of zero). If the controller changes the "Status Type" field part-way through an ACK_OVERFLOW sequence, there's no telling what it will get. Fortunately in case of STATUS_MESSAGES, the response contains the "Status Type" for each of the status reports which should eliminate the ambiguity.
This is probably more of an issue for MFG specific PIDs.
> Is there a bug list for open issues where these
> things are tracked or do people just remember
> to bring them up at the next meeting?
In the past, we've gone through old forum threads before re-opening the document for editing. I think Scott also keeps an errata list.
> It says nothing however about what happens
> if the src UID differs. In multi-controller setups
> like E1.33 we're going to need to be careful to
> ensure one of the following:
This a big part of the reason I don't like E1.33 being multi-controller: It makes ACK_OVERFLOW handling much more complicated. But, multi-controller is highly desirable from an end-use standpoint, so I think the E1.33 gateway will have to initiate the entire overflow sequence on the DMX side, and buffer it for the IP side.
The only other option I can see would be for the E1.33 controllers to all collaborate to make sure ACK_OVERFLOWs are never interleaved, perhaps with a token-ring style "permission to talk" message. For a variety of reasons, I don't think this is practical.
During E1.20 development, there was a lot of discussion of how a responder should handle a change in the controller's UID. We could never reach a consensus. Some felt it should be ignored. Others wanted the responder to un-mute and reset several other protocol elements. In the end it was left un-defined.