Chapter 17 - Introduction to AVD Files
You create or edit collections of attributes in an Attribute View Definition (AVD) file. The AVD file determines the scope and type of information available to users when they use STDA client programs. For example, XSTD can display user phone numbers and scan through attribute information associated with an entry.
AVD files contain labels that map a name to a <v:a> pair, but they do not assign the attributes values. Run StreetTalk management programs to associate values with specific StreetTalk resources.
If the labels in your default AVD file do not suit your needs, you can use a text editor to change them. First, you run the MAVD DOS utility to decompile the binary-formatted AVD file on drive Z to ASCII so that you can view and modify the labels. You then use MAVD again to recompile the modified ASCII file back to binary format. You must copy the modified AVD file to every drive Z so users access the same AVD file.
See Chapter 18 for the AVD conversion procedure.
Note: You must be an administrator with proper administrative privileges to modify or replace the default AVD file (called STANDARD.AVD) on drive Z.
Standard and Default AVD Files
The AVD file, STANDARD.AVD, is placed in one of the following directories:
\MESSAGES subdirectory on the Z drive (native VINES) \Program Files\Banyan\VFILES\DOS\USA\Messages subdirectory (StreetTalk for Windows NT)
This file contains <v:a> identifiers and attribute labels appropriate to most organizations. You can edit the file to suit your requirements or use it as is. In addition, third-party developers of Banyan services and STDA applications supply AVD files specific to the attributes they define and collect.
DEFAULT.AVD File
In addition to the STANDARD.AVD file, a DEFAULT.AVD file is also installed in the same place. Both files are identical. You can use DEFAULT.AVD as a source of AVD information if you modify the STANDARD.AVD file and want to copy original material for use in other AVD files.
As a general rule, do not edit the DEFAULT.AVD file. Leave it as is so you can copy it and replace the STANDARD.AVD in case you make a mistake editing STANDARD.AVD.
Default Collections and Labels
The default attribute labels and attribute collections in the STANDARD.AVD files apply to a broad cross-section of enterprises. Most users on your network will want or need to access these attributes on a regular basis to get such things as information about other users, printers, mail addressing, and network software or third-party services.
The file contains the attribute collections shown in Table 17-1.
| Collection Name | Attribute Labels in the Collection |
| Group Information | Information about StreetTalk groups, such as Description and Rename Status. |
| Mail Addressing | Information about mailing, such as country, mail stop, postal code, and so on. |
| Nickname Information | Real Name attribute label. |
| Printer Capabilities | Information about printers, such as default fonts, paper size, printer type, and so on. |
| Public Keys | Digital signatures used for public/private key encryption schemes. |
| Quick Pick | Information about frequently accessed user attributes, such as job description, phone number, location, and so on. |
| Service Information | Information about services. If you add third-party services to your server, you should add them to this list. |
| Telephone Numbers | Information about telephone numbers such as primary and secondary fax numbers, messaging numbers, and so on. |
| Unabridged | Comprehensive list that includes attributes from all collections in the default file as well as other attributes such as CPR Trained, English, See Also Reference, and so on. The unabridged collection is not dynamically updated when you add a new collection to the default list or use the MAVD utility to merge third-party AVDs with Banyan AVD files. |
| System Specific | Values specific to the system software, such as Mail Service, StreetTalk Class, StreetTalk Category, and so on. |
| X.500 Selected Attribute Types | Values consistent with those defined in the ISO X.500 specification. |
Some attribute labels in an AVD file may apply only to users, and others may apply only to services or groups. Labels have filters to associate attribute labels with one or more classes of objects.
Filters are defined in the FILTERS section of an AVD file. Every resource, whether it is a native StreetTalk object or a third-party service, matches one of these filters and its label.
Each collection of attributes in the AVD file refers to one or more of these filter labels. When users access a particular StreetTalk resource, the resource is matched to a filter. Then the filter's label is compared to each collection in the file. Those collections with matching filter label references appear in the STDA client display; the others do not.
Controlling which collections of attributes appear in STDA client programs based on the class of object being viewed is a central feature of the AVD file scheme. Without some method to control the logical presentation of attributes, users of STDA client programs would see all collections available from the STANDARD.AVD file. Any third-party AVDs compiled with the STANDARD.AVD file would appear as well. By specifying which attribute collections should appear based on object classes, administrators can present information specifically tailored to users' needs.
In many cases, more than one class of StreetTalk resources is associated with a logical collection of attributes:
Attributes in the logical collection "Telephone Numbers" are associated with both "User" and "Nickname" StreetTalk resources. Nearly every StreetTalk resource is associated with the labels in the attribute collection "X.500 Selected Attribute Types." Every StreetTalk resource defined in the filters section is associated with all of the labels in the attribute collection "Unabridged."
Planning attribute definitions is critical to implementing any attribute scheme. Your goal should be to establish a consistent set of attributes that provides users with useful information about your organization's resources. Good planning also makes maintaining attributes for StreetTalk resources in your company easier.
AVD File Definition Guidelines
After you decide what attributes and values users on your network need access to, you can edit the STANDARD.AVD file to match these requirements or create a new AVD file from scratch.
Note: Both editing and creating AVD files must be done at the command line using the MAVD utility. See Chapter 18 for more information.
The following guidelines should make the attribute definition process more manageable:
You can maintain multiple AVD files on your network, but keep the number of separate AVD files to a minimum to avoid confusion caused by redundant or contradictory files.
Unless you have very special requirements, use the STANDARD.AVD file supplied with your Banyan software as the starting point for your attribute definitions. This file contains standard attributes that serve the needs of the general user in most network environments. Unless you intend to have no general user attributes, it is easier to edit the base list than to create a new file from scratch. You are also less likely to make a syntax error if you use the supplied file than if you create a new file.
Bear in mind that you may have no immediate need for some of the collections listed in the default file. As your organization grows or your needs change, however, you may want to use them.
Do not label too many attributes. You can create new attribute collections and additional attributes within existing collections, but remember that each attribute you label means that you or your users need to assign and maintain values associated with the attributes.
Your initial tendency may be to define more attributes than your users need, so exercise moderation. In addition, keep disk space in mind. While attributes do not typically take up much disk space, maintaining a large number of infrequently used attributes is wasteful.
Develop a scheme to propagate revised AVD files across servers on your network. Unless you intentionally decide to maintain variations of AVD files locally, AVD files should be identical on every drive Z on the network. This scheme lets you maintain a consistent view of StreetTalk information for all users.
If you administer a multinational network and use AVDs in multiple languages, you need to devise a scheme to consistently update the various AVD files in different countries.
AVD labels in AVD files do not have be literally identical in both StreetTalk attribute editing menus and STDA client display screens. In fact, the labels used in a display can be in a completely different language as long as their conveyed meaning is consistent with the meaning of the attribute label in both languages.
This feature of attribute definitions has distinct advantages in multinational or multilingual corporate environments.
Example German-English-French Multilingual Example
An administrator in a subsidiary of a company where German and French are the predominant languages can translate the standard STANDARD.AVD list and be certain that values assigned to the English attribute label "Street Address" translate correctly to "Anschrift" in German or "Addresse" in French.
Multilingual AVD files should be identical in conveyed meaning if possible. Where literal translations are not possible, individual attributes and collections of attributes in each AVD file should be consistent with the cultural and textual meaning conveyed in all other AVD files you maintain.
