 
Objectives: 
 
	Plain Text Protocol: 
	You should be able to  'telnet somehost.somedomain 608' 
	and perform a manual transaction. 
 
	Common Format: 
	Whatever format a given file is stored in locally, 
	it is "canonicalized" to an easily understood format 
	for transport on the net, and re-converted (if necessary) 
	at the receiving end.   In other words,  plain text,  binary, 
	record-oriented,  and any other local formats are all 
	mapped to/from well-known (or clearly definable) forms. 
 
	Transport Options: 
	A transfer can be carried by a stream (such as TCP, APPC, 
	or similar protocols) or by store-and-forward (such as "mail" 
	or similar methods) and survives conversion into either form, 
	even multiple "back and forth" conversions.   Thus, if a given 
	system administrator doesn't want to run a UFT server, fine; 
	let his users get everything as MIME.   This puts the choice 
	into the hands of the local administrattion.   But some of us 
	want  "non-mail"  sent by a different channel. 
 
	Extensibility: 
	New attributes and canonicalizations can be added as needed 
	without causing incompatibility with existing clients and servers 
	Even such essential attributes as the NAME of the file may be 
	omitted when they're not available on one end  *or the other*. 
 
	High Level: 
	Ease of implementation in a VHLL such as Tcl, REXX, etc. 
	Not only is the protocol plain text (as stated above), 
	but the files being transferred are represented in a 
	"big picture" way.   Hence,  the  file/metafile  scheme. 
 
 
Why not just use MIME? 
 
	1)  Not Correspondence: 
	The "mail" infrastructure is tuned for correspondence. 
	Quite a few sites have trouble with attachments, 
	and especially with  large files. 
 
	2)  Direct, not queued: 
	A direct protocol also allows for immediate confirmation 
	(or lack thereof) that the file arrived.   But again, 
	with wide deployment of UFT/SIFT,  the local administration 
	could decide which way they prefer things sent. 
 
	3)  Attributes: 
	There's more  "meta info"  carried in SIFT/UFT than is 
	presently carried in MIME.   The defunct Content Type 
	Multipart/Headerset was a good attempt at coping with 
	arbitrary file attribute sets,  but it didn't make it 
	in the MIME working group.   (want to resurrect it?  I'm game) 
 
	4)  Canonicalization: 
	Finally,  UFT/SIFT places stronger emphasis on 
	"canonicalization".   A Content-Type (ala MIME) indicates 
	what kind of processing should be applied to the file 
	once it has been received (or even AS it is BEING received), 
	but it doesn't always indicate HOW the file is to be received. 
	Specifically,  the Content-Type header line doesn't directly 
	say if an object is plain text, binary, or something else, 
	and these are very different things on different systems. 
	While canonicalization should be associated with each MIME 
	Content Type,  it's not always done when the CT is registered. 
 
	Worse,  some Content Types can "switch off";  they're textual 
	one time and binary the next.   For example,  Application/PGP 
	might need to be sent as plain text, or it might need to be sent 
	as binary,  even though it's always processed the same way. 
 
	5)  Delivery: 
	Mail gets redirected.   This is intentional and desireable, 
	but it leaves a niche for SENDFILE to fill.   There are 
	times when you would want to send something to a host 
	on which you do not receive mail. 
 
 
Why not just use NJE over IP? 
 
	1)  It's Proprietary: 
	It's an IBM protocol that is too mainframe-centric 
	to be used on all platforms.   UFT,  however, 
	is simple,  open,  and more general in nature. 
 
	2)  It Doubles the Work: 
	You'd have two networks to maintain,  your TCP/IP network 
	and the NJE network  (which may or may not be layered 
	on top of the IP network). 
 

