PennNames Client - Changes

In designing the PennNames, v.2, 2004-07-14 server efforts were made to continue to honor the existing API but changes in functionality and fixes to existing bugs did result in some changes.

Overview of Changes

• A PennName cannot be added for a person unless that person has an entry in PennCommunity and therefore has been issued a PennID.
  
  The PennNames client commands like ssn_add, ssn_fullname, ssn_id2name, and ssn_relinquish are still supported and still require an SSN as an argument but the PennNames server will query PennCommunity to get the corresponding PennID for the SSN and the command will fail if there is no record in PennCommunity for that SSN.



• Type II conflicts are no longer possible.
  
  While multiple PennNames can still be associated with a single PennID, only one PennName can be "active" at a given time. "Inactive" PennNames are flagged and are not available for use.



• Type I conflicts are no longer possible.
  
  A PennName can only be associated with one PennID.



• The PennNames test server is

  pennnames-test.upenn.edu

  The PennNames client has been distributed with justdoit.isc-net.upenn.edu defined as the test server. We will continue to support that hostname until January, 2005 but we recommend that you change your client to use the new test server name as soon as possible.
  
  To change the test server for your client:
  1. In defines.h, change

     #define TESTSERVER "justdoit.isc-net.upenn.edu"

     to

     #define TESTSERVER "pennnames-test.upenn.edu"

  2. make clean
  3. make
  4. copy the new pennnames binary to your production filesystem



• Certain PennNames commands no longer have functionality.
  
  optdata, along with its counterparts: pennid_optdata and ssn_optdata and conflict report commands: showtypei, and showtypeii are now obsolete. The PennNames server still recognizes these commands but will return a meaningless success code when invoked.



• Added functionality to some PennNames client commands.
  
  The PennNames commands id2name and name2id now take an additional argument that will return all archival PennName and sponsor information available.
  
  The PennNames command hold will now take an additional argument of a PennID that will then hold the PennName for that ID for 3 hours.
  
  The PennNames command generate will now take additional arguments that will be used to further customize the list of available PennNames generated.

Client/Server API Differences

Client command/Server response	Comments
Command:   pennnames session -p [password-file] pennnames session -t Response, v.1:   201 Success A000180798 Response, v.2:   501 Syntax error	The positioning of arguments to the PennNames client is critical but was never documented. If the arguments did not immediately follow "pennnames", they were passed to the server and ignored. Invoking the PennNames client like pennnames session -t resulting in setting a session ID with the primary PennNames server when the intention was to set a session ID with the test PennNames server and the client received no indication that there was any problem. The PennNames, v.2 server will recognize this situation and report it as a syntax error.
Command:   pennnames fullname H00017892 123456789 Response, v.1:   506 ID 123456789 not in PennCard database Response, v.2:   204 Success H00017892 123456789 USER, TEST	The PennNames, v.1 server queried the PennCard database for additional information on a user and reported an error if the user did not have a valid PennCard. The PennNames, v.2 server queries PennCommunity for additional information on a user.
Command:   pennnames id2name H00017892 12345678 Response, v.1:   509 Badly formatted ID 12345678 Response, v.2:   203-Success H00017892	The PennNames, v.1 server id2name expected an SSN and if you tried to use a PennID as an argument to id2name, the server considered that an error. The PennNames, v.2 server id2name will take either an SSN or a PennID as an argument.
Command:   pennnames generate H00017892 15 12345678 Response, v.1:   509 Badly formatted ID 12345678 Response, v.2:   203-Success H00017892	The PennNames, v.1 server generate expected an SSN and if you tried to use a PennID as an argument to generate, the server considered that an error. The PennNames, v.2 server generate will take either an SSN or a PennID as an argument.
Command:   pennnames relinquish H00017892 joeuser 12345678 Response, v.1:   509 Badly formatted ID 12345678 Response, v.2:   203 Success deleted 1 sponsors, 0 names	The PennNames, v.1 server relinquish expected an SSN and if you tried to use a PennID as an argument to relinquish, the server considered that an error. The PennNames, v.2 server relinquish will take either an SSN or a PennID as an argument.
Command:   pennnames fullname H00017892 12345678 Response, v.1:   509 Badly formatted ID 12345678 Response, v.2:   204 Success H00017892 12345678 USER, TEST	The PennNames, v.1 server fullname expected an SSN and if you tried to use a PennID as an argument to fullname, the server considered that an error. The PennNames, v.2 server fullname will take either an SSN or a PennID as an argument.
Command:   pennnames optdata H00017892 ... pennnames pennid_optdata H00017892 ... pennnames ssn_optdata H00017892 ... Response, v.1:   201 Success Response, v.2:   201 Success	The PennNames, v.1 server optdata, pennid_optdata, and ssn_optdata commands were used to store "optional" data but there was no utility developed to access this optional data and we will no longer store this data. These commands have no functionality in the PennNames, v.2 server. To assure that scripts which may be using these commands do not break, the PennNames, v2 server will continue to return a successful response but no optional data is actually stored.
Command:   pennnames showtypei H00017892 pennnames showtypeii H00017892 Response, v.1:   203-Type I joeuser 123456789 12345678 05-SEP-2003 203-Type I joeuser 123456789 12345678 05-SEP-2003 Response, v.2:   203 Total type-I conflicts: 0 203 Total type-II conflicts: 0	The PennNames, v.1 server showtypei and showtypeii commands were used to list Type I and Type II conflicts. Since Type I and Type II conflicts can no longer exist in the PennNames, v.2 server, these commands have no functionality in the PennNames, v.2 server. To assure that scripts which may be using these commands do not break, the PennNames, v2 server will continue to return a successful response.