{verbatim}
-The "TransferDaemon" feature of Condor exists in four major parts:
+The "TransferDaemon" feature of HTCondor exists in four major parts:
 
 1. A standalone daemon called the TransferD which wraps the FileTransfer object.
 2. A "transfer daemon manager" which is an object in the schedd, but could
@@ -14,7 +14,7 @@
 
 The purpose of this feature was three fold:
 
-1. To be able to transfer files to and from Condor controlled endpoints
+1. To be able to transfer files to and from HTCondor controlled endpoints
   (which might not be the actual submit machine) asynchronously and under
   priviledge separation scenarios.
 
@@ -93,7 +93,7 @@
 associated with the transfer desired. Depending upon the file transfer
 protocol specified, they could be jobads or some other kind of ad
 describing what to do to some backend of the TransferD. Since the code
-only supports the "Condor File Transfer Protocol" as defined by the
+only supports the "HTCondor File Transfer Protocol" as defined by the
 FileTransfer object, these ads are just a list of jobads.
 
 The class' constructor can take a classad (whose schema is enforced