Area

Storage

(Internal Representation on Disk)

GUI

(Allowed and Displayed)

Usage

(When EFT Server or SAT uses the value)

Remarks

General

All domain (host) fields (SAT and EFT Server)

Unicode

(stored in Punycode in SAT)

Unicode

7-bit ASCII

IDN (Internationalization of Domain Names) support by converting Unicode to Punycode upon use. From a user (presentation) perspective and EFT Server’s internal representation, it will be Unicode.

All email address fields (SAT and EFT Server)

Unicode

7-bit ASCII

7-bit ASCII

Conversion to Unicode for storage, but downgrade on usage. No risk/potential for loss of fidelity, as all chars limited to <128 ASCII.

You can paste in Punycode ASCII characters directly for the domain portion if you must have Unicode domains for email addresses.

SMTP settings (username + password)

Unicode

7-bit ASCII

7-bit ASCII

Conversion to Unicode for storage, but downgrade on usage. No risk/potential for loss of fidelity, as all chars limited in GUI/usage to <128 ASCII.

Installer

8-bit ASCII

8-bit ASCII

8-bit ASCII

See Installer – ASCII ONLY below for potential problems

Keys and PGP

SSL CN field

8-bit ASCII

8-bit ASCII

8-bit ASCII

RFC allows for Unicode but OpenSSL handles the value as ASCII

SSL priv. key pass

8-bit ASCII

8-bit ASCII

8-bit ASCII

Passwords stored as octects sequence using same encoding as UI (ASCII)

SSH priv. key pass

8-bit ASCII

8-bit ASCII

8-bit ASCII

Passwords stored as octects sequence using same encoding as UI (ASCII)

PGP priv. key pass

8-bit ASCII

8-bit ASCII

8-bit ASCII

Veridis limitation. Passwords stored as octects sequence, 8-bit ASCII.

PGP filename and pathnames

n/a

n/a

8-bit ASCII

Unicode filenames will be supported, but the will be temporarily converted to ASCII.

PGP key name

8-bit ASCII

8-bit ASCII

8-bit ASCII

PGP module does not support Unicode

PGP public and private key ring paths

8-bit ASCII

8-bit ASCII

8-bit ASCII

PGP module does not support Unicode

RSA

RSA Conf.reg path

8-bit ASCII

8-bit ASCII

8-bit ASCII

RSA dll only takes ASCII path values

RSA usernames and passwords

Unicode

Unicode

8-bit ASCII

RSA does not support Unicode. We will downgrade to ASCII on usage. Potential loss of fidelity resulting in failed authentication attempts.

ARM

ARM report content

Unicode (audited)

8-bit ASCII

(reported)

8-bit ASCII

(reported)

Loss of fidelity for UTF-8 chars that don’t match local code page for ext. ASCII

AS2

AS2 outbound

n/a

n/a

8-bit ASCII

AS2 does not support Unicode encoded filenames. We can’t downgrade to ASCII as we would be violating Drummond, thus we will simply disallow and log error.

AS2 inbound

n/a

n/a

8-bit ASCII

AS2 does not support Unicode encoded filenames. Unlike offloads, EFT Server inbound can’t detect whether the incoming file is Unicode encoded or not, thus we will always hand the file off to the AS2 component, with potential for mixed results. The outcome either be: a) an ASCII encoded filename, b) a failed transaction, or c) an ASCII encoded unique filename. Reference the AS2 Inbound Operations Use Case Cheat Sheet for additional guidance.

RADIUS

RADIUS NAS ID

Unicode

8-bit ASCII

8-bit ASCII

EFT Server 6.4 used 8-bit ASCII. EFT Server 6.5 will represent as UNICODE strings (internally) and then downgrade to 8-bit ASCII on use. Also limited to ASCII in UI.

RADIUS special cases

RADIUS shared secret

Unicode

Unicode

UTF-8

RFC says nothing about RADIUS password. EFT Server 6.4 used 8-bit ASCII. EFT Server 6.5 uses UTF-8. This difference (between earlier versions of EFT Server and version 6.5 and the resulting potential loss of fidelity is why this item is included on this list (even though it is UTF-8)

RADIUS usernames

Unicode

Unicode

UTF-8

According to relevant RCS, RADIUS usernames and the shared secret can be UTF-8 strings.  

HTTP

EFT Server client action HTTP/S credentials

Unicode

n/a

Base64 encoding of UTF-8 string

S5: Presently we Base64 on UCS2 string. We are working to change it to the one used in server part of HTTP (Base64 on UTF-8).

EFT Server client action HTTP/S Proxy

Unicode

n/a

Base64 encoding of UTF-8 string

Same as above.

AS2 client compliance with RFC 2184

File encoding of source file on disk

Resulting change to file encoding in transit

EFT Server treatment (resulting encoding and/or loss of fidelity)

Standard AS2 client. Does not comply with RFC 2184. It relies on filename=<text encoded in asciiI>

NOTE: Majority of known AS2 clients

ASCII

ASCII

(no change)

Filename integrity maintained. No loss of encoding fidelity. Normal use case. This is essentially 7 and 8-bit ASCII transfers when working with standard ASCII only AS2 clients works perfect.

Unicode

ASCII – down converts to "??????" or nonsense characters.

/n component will fail to process because "????" is an  invalid filename. The transfer will result in a failure to write to disk. EFT Server must log this as an error in eft.log.

AS2 client is compliant with RFC2184. That is,  uses filename*= utf-8''<text encoded in UTF-8>

ASCII

ASCII

(no change)

Filename integrity is NOT maintained. /n component will process but will convert the filename to a unique 8-bit ASCII filename; however there won’t be a loss of encoding fidelity.

EFT Server will log as warning that filename was changed.

Unicode

Unicode

(no change)

Filename integrity is NOT maintained. /n component will process but will convert the filename to a unique 8-bit ASCII filename; There is also a loss of encoding fidelity as it is down converted to ASCII. EFT Server will log as warning that filename was changed.

AS2 Other/Miscellaneous Limitations

AS2 ID (identifier)

ASCII only

ASCII only

EFT Server displays a message indicating that Unicode is not allowed.

If source filename is:

If source path is:

Resulting SDA name:

If extract path is

Result

Unicode

n/a

n/a

n/a

Will fail to generate SDA

ASCII

Unicode

ASCII

ASCII

Works perfect. Everything preserved

ASCII

ASCII

Unicode

ASCII

Unicode

Will fail to extract

ASCII

Value

EFT Server Installer Impact

SAT Installer Impact

Customer support mitigation strategy

Admin credentials

No affect if changed as subsequent installs or upgrades do not query or use this value.

If you install EFT Server, then modify admin name to Unicode, then attempts to install SAT, you will NOT be able to connect to EFT Server using the admin name with Unicode credentials.

Change admin credtials back to non-Unicode or create a separate admin account with COM priviledges and then use that admin from SAT installer.

Site Name

No impact; EFT Server installer does not use.

SAT installer will not be able to display the Site name in the installer

Create a separate Site in EFT Server using ASCII only, then use that Site from the SAT installer. If necessary modify the SAT config xml to reflect the original Unicode Site name, but don’t forget to move all scripts and such from second (ASCII) Site over to the primary site (Unicode) or SAT won’t work properly.

ARM config

Can affect future upgrades to EFT Server;  user cannot enter Unicode values in fields during upgrade

No affect; SAT uses COM to communicate auditable changes to EFT Server

Do not use Unicode for ARM values. If you do, then future upgrades of EFT Server will not work (until our installer supports Unicode). You should change ARM values back to ASCII before performing an upgrade.

SMTP settings

No affect

SAT uses these values and will fail to write to config properly

Use only ASCII in EFT Server interfaces for SMTP values or use bogus values during SAT installation, then modify the config.xml to reflect the Unicode values after installation is complete and SAT is working.

App data path  (configurable value in EFT Server)

Future EFT Server upgrades will fail; the installer cannot retrieve the app data path if in Unicode

No affect/not used

Do not use Unicode characters for app data path. If necessary, change back to ASCII path (don’t forget to move all files over) then run EFT Server installer/upgrader.