Issue 1836: Add find_or_register operation to CorrelationMgr interface (pids-rtf2) Source: (, ) Nature: Revision Severity: Summary: Summary: 2) Change PIDS interfaces a) Add a "find_or_register" operation to the CorrelationMgr interface that accepts a QualifiedTaggedProfileSeq instead of a TaggedProfileSeq like the IdMgr find_or_register operation. This would make the requirement for the QualifiedPersonId explicit. b) Add a new operation to the IdMgr interface called "add_external_ids". This would allow an explicit agreement and the part of the client and non-correlating service to track uncorrelated identifiers. A PIDS service could return NotImplemented if it doesn"t track external ids. A correlating PIDS service could also return NotImplemented if it doesn" t track non-correlated ids. I have attached the revised IDL for the IdMgr and CorrelationMgr interfaces. We like these changes because they make the requirement for the QualifiedPersonId explicit as well as removing the ambiguity associated with the ExternalIds trait. We appreciate all the thought that has gone into the PIDS specification and understand that our needs might be met in a more creative way that does not require any changes to the PIDS specification. We would appreciate any feedback you have. Resolution: Update spec as below. Revised Text: Add the follwoing operation to CorrelationMgr: Actions taken: August 18, 1998: received issue February 25, 1999: closed issue Discussion: End of Annotations:===== Return-Path: From: "Chris White" To: Cc: "Tim Brinson" , "John Landers" , "Jon Farmer" Subject: Issues with PIDS spec - unattended correlation Date: Tue, 18 Aug 1998 09:58:36 -0400 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Great job on the PIDS spec! Everyone who worked on it should feel very proud! size=2> We have an issue that we encountered as we were implementing the PIDS. These have to do with unattended matching with a correlating PIDS. The IdMgr interface supports unattended matching via the find_or_register operation. However, this operation does not exist on the CorrelationMgr interface. This is a problem because correlation REQUIRES an QualifiedPersonId which is not available in any argument to the IdMgr find_or_register interface. size=2> It has been suggested that we require PIDS clients that want correlation pass in a QualifiedPersonId in the "PIDS/ExternalIds" trait. However, we find the use of this trait ambiguous. The spec says: size=2>"This trait indicates the set of other IDs a person may have. The IDs listed may be from a different ID Domain than the ID Domain of the ID this trait is bound to. This is more general purpose than CorrelatedIds. The IDs listed in this trait may be set by other mechanisms than automatic correlation." size=2> face=Arial size=2>So we cannot tell if the client wants the QualifiedExternalIds correlated or not. We also think that this will probably create interoperability problems because the requirement for a QualifiedPersonId is not explicit. size=2> We are suggesting the following changes. One is simply a documentation clarification. The 2) Change PIDS interfaces size=2> face=Arial size=2>a) Add a "find_or_register" operation to the CorrelationMgr interface that accepts a QualifiedTaggedProfileSeq instead of a TaggedProfileSeq like the IdMgr find_or_register operation. This would make the requirement for the QualifiedPersonId explicit. size=2> face=Arial size=2>b) Add a new operation to the IdMgr interface called "add_external_ids". This would allow an explicit agreement and the part of the client and non-correlating service to track uncorrelated identifiers. A PIDS service could return NotImplemented if it doesn't track external ids. A correlating PIDS service could also return NotImplemented if it doesn' t track non-correlated ids. size=2> face=Arial size=2> face=Arial size=2>I have attached the revised IDL for the IdMgr and CorrelationMgr interfaces. We like these changes because they make the requirement for the QualifiedPersonId explicit as well as removing the ambiguity associated with the ExternalIds trait. size=2> We appreciate all the thought that has gone into the PIDS specification and understand that our needs might be met in a more creative way that does not require any changes to the PIDS specification. We would appreciate any feedback you have.