These settings will apply to the CCK field in every content type in which it appears.

The form returned with the "form" operation will be displayed in the Global Settings fieldset when you select (or add) the field on the Manage Fields page on the Content Type configuration (Content Management->Content Types menu). This information is applied globally to this field for each instance of the content type. (Do not confuse this field with the data entry field.)

/**
* Handle the parameters for a field.
*
* @param $op
*   The operation to be performed. Possible values:
*   - "form": Display the field settings form.
*   - "validate": Check the field settings form for errors.
*   - "save": Declare which fields to save back to the database.
*   - "database columns": Declare the columns that content.module should create
*     and manage on behalf of the field. If the field module wishes to handle
*     its own database storage, this should be omitted.
*   - "filters": If content.module is managing the database storage,
*     this operator determines what filters are available to views.
*     They always apply to the first column listed in the "database columns"
*     array.
*   - "views data": Tell Views how to handle your field. This is mostly useful for
*     CCK fields that themselves contain multiple fields, such as a name with
*     first, middle and last.
* @param $field
*   The field on which the operation is to be performed.
* @return
*   This varies depending on the operation.
*   - The "form" operation should return an array of form elements to add to
*     the settings page.
*   - The "validate" operation has no return value. Use form_set_error().
*   - The "save" operation should return an array of names of form elements to
*     be saved in the database.
*   - The "database columns" operation should return an array keyed by column
*     name, with arrays of column information as values. This column information
*     must include "type", the MySQL data type of the column, and may also
*     include a "sortable" parameter to indicate to views.module that the
*     column contains ordered information. Details of other information that can
*     be passed to the database layer can be found at content_db_add_column().
*   - The "filters" operation should return an array whose values are 'filters'
*     definitions as expected by views.module (see Views Documentation).
*     When providing several filters, it is recommended to use the 'name'
*     attribute in order to let the user distinguish between them. If no 'name'
*     is specified for a filter, the key of the filter will be used instead.
*   - "views data": Return an array where entries look similar to this -
*      $data[$table_alias][$field['field_name'] .'_'. $ftype] = $field_cck;
*      where $table_alias can be had from content_views_tablename($field),
*      $ftype is one of the keys from your 'database columns',
*      and $field_cck is itself an array of overriden elements from a call to
*      content_views_field_views_data($field).
*      ex. $field_cck['title'] .= ' '. $field_data['title'];
*           $field_cck['title_short'] = $field_data['title'];
*           $field_cck['field']['field'] = $field['field_name'] .'_'. $ftype;
*           $field_cck['argument']['field'] = $field['field_name'] .'_'. $ftype;
*           $field_cck['filter']['field'] = $field['field_name'] .'_'. $ftype;
*           $field_cck['filter']['title'] .= ' '. $field_data['title'];
*           $field_cck['sort']['field'] = $field['field_name'] .'_'. $ftype;
*      There may be other keys in that array. (?)
*/