|
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 );
|