How does this logic sound:
The bridge has a zone name and network number that can be manually configured. On startup it does a GNI to verify that they're valid if there's a router on the ET side of the network. If GNI response says they are, great. If the GNI response says the zone name is not valid, the bridge adopts the default zone name. If the GNI response says the network number is not valid, the bridge adopts the first network number in the range. If there is no GNI response, the bridge adopts "*" as its zone and the last known network number as its network number (or a random one in the startup range if there is no last known network number). We only do the GNI query on startup. The bridge does not care if a router appears after startup. In any case, having acquired a zone name, it starts listening on the corresponding multicast Ethernet address.
When AppleTalk or AARP frames are seen on the ET side of the network from the bridge's network number, their source node numbers are marked as in use on the ET side by the bridge (with a timeout of some kind), which then alerts TashTalk to respond to ENQs and RTSes on their behalf. Likewise, when frames are seen on the LT side of the network, their source node numbers are marked as in use on the LT side by the bridge (again, with a timeout). When AARP request or probe frames come in on the ET side for node numbers on the bridge's network number that the bridge has marked in use on the LT side, the bridge responds to them appropriately. By way of keeping the node table up to date, before timing out an entry, the bridge will send AARP probes (for nodes on the ET side) or ENQ frames (for nodes on the LT side) to prompt the node to respond and have its timeout reset.
When AppleTalk frames come in on the ET side for the bridge's network number, they are translated across to LT frames and sent on the LT side. When frames come in on the LT side for node addresses known to exist on the ET side (or broadcast frames), they are translated across to ET frames and sent on the ET side (frames for unknown addresses won't be known to TashTalk and won't get CTS frames, so they won't be relayed).