Since Nicholas Horelik (email@example.com) is on this WG, he may have already brought this up, but here is something that was reported during ICE 7 testing. If so just close this out as not an issue.
The standard allows for multiple Call-Info headers to be present in a SIP INVITE, where each one would contain a dereferencing link to a different additional data block. It is possible and likely in certain scenarios for intermediate functional elements (e.g. an ESRP) to add more Call-Info headers when calls pass through them (e.g. if they add more provider info, or if they pull additional location info from an ECRF). In addition, it is possible for these data blocks to also be added by value into the INVITE, either by the originator or by intermediate functional elements, or by both. In addition, it is possible for an IS-ADR to be queried from any functional element, or by the call handling or CAD at the PSAP.
Ultimately however it is generated, the problem is that we are likely to end up at the PSAP with more than one additional data document for one or more data block types. At the event, we saw that all PSAP implementations were only expecting one data document per data block type, and thus could only display one. Usually they would display to the call-taker only the latest one they received, and discard the rest.
There is no clear guidance in the standards for how to handle this scenario that anyone at the event was able to cite. I would recommend that the existing setup of flexibility in the SIP signaling be maintained, and a note or requirement be added to the standards indicating that downstream elements at a PSAP should have the ability to display multiple data blocks in one manner or another (e.g., by showing each set in a different tab or window). I would think that this doesn't need to be too perscriptive: each vendor could handle presentation in a different way, as long as the ability to display all received information is present.