XDS: Incorrect validation of RegistryError.location about ipf HOT 4 CLOSED

@qligier : For XCA (https://profiles.ihe.net/ITI/TF/Volume2/ITI-38.html#3.38.4.1.3), it looks like there is a more specific description is present: Ensure that every RegistryError element returned in the response shall have the location attribute set to one of the homeCommunityIds of the Responding Gateway. which would fit to the current implementation from my point of view. From implementation view, it looks like XCF, XCDR, XCA and RMU are currently enforcing the OID rule (not checked if all of them define a rule like XCA does).

My interpretation of the general location definition with "if appropriate" is, that everyone can decide if there is a benefit for this. From security point of view, i would not expose too much detail here and i also do not see any benefit for a client knowing this details.

@unixoid: Since you already assigned it, do you have any thoughts what aspect should be changed?

from ipf.

Actually, putting the home community ID into @location is necessary only for ITI-38 and ITI-39. Done it this way.

from ipf.

@Thopap Interesting, thanks! I have checked the XCA ITI-39 transaction and the requirements are different:

ITI-39 Expected actions

If the Responding Gateway returns any Registry Error elements, the Responding Gateway shall include in the location attribute all the requirements stated in Section 3.43 plus the homeCommunityId of the Responding Gateway.

ITI-43 Protocol Requirements

@location contains the DocumentUniqueId of the document requested

In that case, the result seems to be a string made of the DocumentEntry.uniqueId and the homeCommunityId.

From a quick search, I could not find specific requirements for RMU, XCF or XCDR.

@unixoid Thanks for the quick patch!

from ipf.

It is interesting that IHE prescribes to preserve ITI-43 @location in ITI-39 responses, but not ITI-18 @location in ITI-38 responses...

from ipf.