Chapter 15 - Introduction to Attributes
An attribute is a property of a StreetTalk resource or object.
Note: When the attributes of a StreetTalk resource are managed, the resource is referred to as an object. For example, John Blake@Admin@WCTAR is a StreetTalk object.
Attributes are like variables in a programming language. They have a name, type, and can be read or written to. Each StreetTalk object can have its own set of attributes. For example, users can have multiple attributes representing their phone number, address, and so on that let you make useful and commonly used information about them available to all users on your network. You can add, delete, modify, and display most attributes. However, some attributes are read-only.
This chapter describes the attribute-related concepts that you need to understand:
Identifiers Labels Collections Filters Values Data Types
StreetTalk Classes and Attributes
Table 15-1 shows the classes attributes can be assigned to and lists some examples of possible attributes for these classes:
Class | Refers To... | Example of Attribute |
Users | User names | Phone number, fax number, office location, office hours, mail stop |
Services | All services such as print, file, asynchronous, 3270 SNA, and Netbios | Location, configuration parameters, AFP, service administrator |
Lists | Lists of users, services, nicknames, and other lists | Home server, item modify time |
Groups | StreetTalk groups that contain of the above | Location, group administrator any or all |
Note: Attributes cannot be assigned to nicknames independently of attributes for the complete StreetTalk usernames. Banyan management tools let you configure attributes for a nickname but those attributes are also configured for the full name of the StreetTalk user.
An attribute identifier is a number pair that defines the attribute for StreetTalk and STDA. Every attribute is identified by a two-number vendor-attribute pair with the following format:
<v:a>
where v is the vendor number, a is the attribute number.
Banyan reserves vendor numbers for:
VINES or StreetTalk for Windows NT Third-party Developers of VINES applications Administrators
Within the range of assigned vendor numbers, attribute numbers can be specified by:
Developers of third-party applications in Attribute View Definition (AVD) files they provide with their products Network administrators in the Standard Attribute View Definition file provided by Banyan
AVD files are described in a later section.
Third party software developers are assigned vendor numbers.
Table 15-2 lists the range of vendor numbers for attributes and their assignment.
Vendor Number | Description |
0 | Reserved for attributes that Banyan defines. |
1 |
Reserved for Banyan internal use. Vendor-attribute identifiers that begin with 1 are used to insure backwards compatibility with attribute information entered in earlier revisions of your network software. Banyan reserves the right to assign everything above 1:999. Do not use this vendor number in a collection parameter. |
2 | An unregulated number third-party developers use to test new software before an official vendor number is assigned. Do not use this vendor number in a collection parameter. |
3 | Recommended for customer-specific attributes. Administrators who want to define attributes in addition to those defined by Banyan should put them in the 3:* range. |
4 to 232 |
Assigned by Banyan to developers and customers. Customers are issued one number. Software vendors should have one number to for each separate product they adapt to their network software. Services can also request vendor numbers from this range. Administrators are discouraged from using numbers in this range. |
Using numbers to represent attributes makes them language independent. An English-speaking administrator can assign the user class attribute <0:111> the label (described below) "telephone." A German-speaking administrator can map the same attribute to "Telephon." StreetTalk recognizes the attribute regardless of its English or German label.
Users and administrators do not modify <v:a> numbers.
Users or administrators who run StreetTalk programs or STDA can display attributes according to the attribute's label. A label is a name assigned to the attribute identifier. For example, StreetTalk shows that the following <v:a> pairs are assigned these labels:
<v:a> Pair | Label |
<0:1> | Description |
<0:5> | StreetTalk Group |
<0:13> | Home Server |
<0:17> | Formatted Name |
<0:111> | Telephone Number |
All StreetTalk objects have some default attributes and labels that Banyan specifies. For example, the StreetTalk object John Blake@Admin@WCTAR has the labels "StreetTalk Group," "Telephone Number," and others associated with it.
The mapping between attribute labels and the <v:a> pairs are stored in the Attribute View Definition (AVD) files (STANDARD.AVD and DEFAULT.AVD). AVD files are stored in the MESSAGES subdirectory on drive Z. They are in binary format but can be decompiled to text format for editing. If a default label is not appropriate, a label can be edited.
Normally the same labels apply to both network users and administrators and appear in both STDA and StreetTalk client programs. Users see attribute labels when they use STDA client applications to access attribute information. Administrators see them when they assign values to attributes in StreetTalk management programs. Values are described in a later section.
Attribute Collections
In addition to having individual labels, attributes can be grouped into collections, each of which has its own label. For example, "Mailing address" is a label for this default collection of attributes with these labels:
Country Mail Stop P.O. Box Postal Code State/Province Street Address Town/City
Attribute collections are a convenience that help make sense out of large numbers of attributes that have some logical relationship to one another.
Some attribute labels or collections of labels may apply only to one StreetTalk class. Other labels may apply to more than one StreetTalk class. To associate attribute labels with one or more classes of objects, labels have filters.
The attributes in the "Telephone Numbers" collection can be configured to appear when StreetTalk "User" resources are accessed because phone numbers are usually associated with users. You do not want the collection "Printer Capabilities" to appear when you access a StreetTalk "User" resource because printers are not logically related to users. Little or no logical relationship exists between the two classes so neither collection has filter references to the other. This relationship is shown in Figure 15-1.
Attribute identifiers have default labels but most do not have any default values. An attribute value uniquely describes the attribute of a StreetTalk object.
Example The Value of an Address
The attribute <1:106> has no value until a user or administrator edits the attribute and adds a real address to it for one or more users. Attribute <1:106> in the AVD file has the label "Street Address." Users accessing information from STDA or StreetTalk client programs will see "115 Elm" displayed under the label "Street Address" when they look up Jane Smith@ Chicago Sales@WCTUS if these conditions are met:
Attribute <1:106> is assigned the string value "115 Elm" for Jane Smith@ Chicago Sales@WCTUS. The attribute identifier <1:106> is in the AVD files that are located on every drive Z that users can access. STDA services are configured to collect and display this attribute.
Some attribute identifiers, default attribute labels for Jane Smith, and examples of assigned values are shown in Table 15-4:
Attribute Identifier | Default Label | Assigned Value |
<0:109> | Country | USA |
<0:110> | Postal Code | 60611 |
<0:108> | State or Province Name | Illinois |
<0:106> | Street Address | 115 Elm |
<0:107> | Town/City | Chicago |
You must run a StreetTalk administrative program to assign a value to an attribute as described in Chapter 19.
Data Types
Attribute values can be represented in any of the data types shown in Table 15-5.
Data Type | Description |
Boolean | Used to indicate true or false. An attribute implies true; lack of an attribute implies false. For example, a collection of attributes called Computer Skills might contain attributes used to establish network users' skills with PC and business software programs. Network users could use Boolean values to search on the DOS attribute or some other pre-determined attribute to find users whose skills match their requirements. |
Binary | Commonly assigned by applications developers for programming purposes. Bitmapped images are binary data types. |
String | The default data type for attributes. This type is commonly used to enter values for attributes such as "Building" , "Location," "Telephone Number," and so on. |
Integer | Commonly used by programmers to store and check values. Attribute values can be expressed as positive or negative numbers between -2147483647 and 2147483648 (-231 + 1 to 231). Multiple integer values can be entered to a limit of 4096 characters in the editing screen. Multiple integer values of any size can be imported as files. |
ASN.1 | Commonly used by applications which format data using X.500 binary encoding rules. ASN.1 follows closely the formatting rules for binary data types. |
See Chapter 19 for more information on data types.
Figure 15-2 shows the relationship between the components of attributes.
Effectively implementing an attribute scheme is not difficult, but it requires planning. Planning activities can be broken into four stages:
1. Analyze your organization.
2. Specify attribute labels.
3. Assign values.
4. Collect and display attributes.
Following these steps in order is important. Systematically defining and controlling attributes provides users with a consistent view of attribute values across your network and makes future administration of attributes easier. Although you should follow these steps, nothing prevents you from changing any aspect of your attribute scheme later.
Understanding the information needs of users and administrators on your network is a prerequisite to implementing any attribute scheme. Give careful thought to the types of attributes users in your organization would find useful and how attributes will be maintained once they are established.
To make effective decisions about which attributes users should see, think about your enterprise's information requirements. In particular, ask yourself the following questions:
What information do most users need to find all the time? Do individuals or groups in your organization need to collect unique information for access or tracking purposes by other users? For example, a human resources group can track emergency medical data about who in the company has CPR training. As an administrator, do you need to track software, hardware, or other network-specific information? Does your network span national boundaries and language groups?
The answers to each of these questions affect how you edit or create attribute definition lists for your network.
In most circumstances, you want users on your network to see everything available in the default attributes shipped with Banyan software. If so, simply use the standard list supplied with the Banyan network software without modifying it.
After you analyze your requirements and plan your attributes, you can specify a set of attribute labels. First look at the default set of attributes and attribute labels supplied with your software. These are attributes commonly used in corporate and educational environments. You may decide that you do not need to modify this list. You may need to create multiple lists of labels in different languages. If you must, you can edit the list or create an entirely new one, replacing the default list.
To change labels, you use the MAVD utility to convert an AVD file to text format. Then, you use a text editor to view and modify the labels. Lastly, you use MAVD to recompile the modified ASCII file to binary format. See Chapter 17 for more information.
You must be an administrator with proper privileges to replace the default AVD file on drive Z.
After you define the attribute labels you want to collect and display, you or your users assign values to the attributes using a Banyan management tool to perform the following tasks:
Establish the value and data types of attributes. Replace attribute values with the contents of files. Write attribute values into files.
The attributes you edit in the Banyan management tool have labels identical to those assigned in the edited AVD file. They are also identical to the labels users see in STDA client applications provided all users access the same AVD file when they run the client program.
Displaying Attribute Information
After you add attribute labels to attribute identifiers and assign values to the attributes, you determine which attributes STDA captures and makes available to users. For example, XSTD can display user phone numbers and scan through attribute information associated with an entry.
You can also configure STDA so that users searching in an STDA client program for attribute information on other users, do not see some collections.
Chapter 20 describes how to collect and display attributes