It has also been noted that several of the length restrictions on metadata values are too small and no longer needed in the current computing environment.

Several changes are proposed to metadata tables and metadata management specifications.

3.1.1 Version Management

Currently, RETS specifies the use of version numbers for version management. Version numbers are required to increase when any element changes, with ripples through the hierarchy. The version numbering mechanism is specified with a <major>.<minor>.<release> convention, but the convention is not binding.

It is proposed that version numbering as a control mechanism be deprecated, and that metadata advertising and acceptance be based instead on the modification timestamp for the metadata. Section 4.7.3 will be modified to include MetatdataTimestamp and MinMetadataTimestamp values; these are to be compared with the Date attribute of the System metadata to determine whether the client has an acceptable version of metadata.

Section 4.7.3 of the specification will be further amended to indicate that a client MAY retrieve the newer metadata version from the host if it finds that its stored version is earlier than the MinMetadataTimestamp. If the client chooses not to obey this advisory, then query results are not guaranteed to be correct and may result in errors or incorrect information being supplied to the client.

Section 4.4 will be amended to include an optional parameter, SavedMetadataTimestamp. The value is strictly advisory for the server; the server MAY use this to adapt to a metadata version earlier than its advertised MinMetadataTimestamp, but is not required to do so. It may also use the information for logging or any other purpose.

3.1.2 Metadata Comparisons

In order to facilitate metadata comparisons, a known-invariant field, named MetadataEntryID, is to be added to every metadata row in every table except System, Resource and Class. This field, a 32-character string, is to be maintained by the server and can be used by the client to indicate that a particular row has the same logical meaning despite changes in its fields. For example, the invariant field may be used to detect changes in the SystemName in the Table metadata.

It is not the intent of the specification to force servers to create a new logical data item. If one of the metadata fields already serves this purpose, its value can be duplicated in the MetadataEntryID field. The client MUST treat this field as opaque, and not try to interpret its contents.

3.1.3 Length changes

In general, the objective is to avoid having the standard impose arbitrary limits on human-readable fields.

Table	Field	Old	New	Rationale
METADATA-CLASS	VisibleName	32	64	Old length was inadequate for a prose description.
	Description	64	128	Old length was inadequate for a prose description.
METADATA-TABLE	ShortName	24	64	Old length was inadequate for a prose description.
	LongName	32	256	The field should be able to contain arbitrary text.
METADATA-OBJECT	MIMEType	24	64	Old length was inadequate for some MIME type designations.
	VisibleName	32	64	Old length was inadequate for some prose descriptions.
	Description	64	256	The field should be able to contain arbitrary text.
METADATA-LOOKUP_TYPE	LongValue	32	128	The field should be able to contain arbitrary text.
METADATA-SEARCH_HELP	Value	128	1024	The field should be able to contain arbitrary text, including examples.
METADATA-UPDATE_HELP	Value	128	1024	The field should be able to contain arbitrary text, including examples.