From: Gill, J. <joh...@tg...> - 2002-04-19 20:35:07
|
I wanted to give this topic plenty of thought exposure. Request: Tim Wenger has proposed that a function be added to assist the situation where some software (SBS's etc) only cares for a specific portion of a keyID, and not the whole keyID string. In general this would not work but in the specific cases of EEAT transactions this would work, because of the NCHELP & Education Department's control over Office of Education ID's. EEAT and NCHELP as a whole have been using these uniquely assigned id codes to identify the routing points in a B2B transaction. The NCHELP/EEAT Technical Manual specifies that the KeyID start with the company name that this key represents and that the comment contain the DOE# (ie. An entity("TEST COMPANY" with a DOE. number of "11111111" and non-ED branch ID of "ABC1", would have a key ID string of "TEST COMPANY (DOE.11111111.ABC1)". It should also be remember that the email addresses are considered optional in the EEAT data exchange world. That's what the "profile tables" are for!!!) Proposed solution(CmdrX): I propose that a function call be added to the DLL to allow for limited information to be passed in the resolution of a keyID. Function LimitKeyResolve(UserName,KeyID,EmailAddr: PCHAR): PCHAR; This function would take what items the user provided and try to resolve the key from the limited set of information. If the calling program does not have a specific piece of information then it would pass that information as a "null" value(ie "PCHAR('')" ). Problems with this suggestion.. there is no way to return an error message should the function fail. Envisioned usage: In the encrypt function ("Encrypt(SourceFile,ResultFile,KeyID:PChar)") I would see this function working like this... Encrypt(SourceFile, ResultFile, LimitKeyResolve(UserName,KeyID,EmailAddr) ); Because of the problem I identified with error trapping tmpstr := LimitKeyResolve(UserName,KeyID,EmailAddr); if no error then Encrypt(SourceFile, ResultFile, tmpstr ); |