• Optional Client Request Header Field: Metadata-Version to be included for all RETS Transactions.
• Additional RETS Reply Code: 20038, Meaning: Metadata Version ##.##.#### is expired and cannot be supported
• Changes the way the Metadata Version Tags section on pg. 4-4 of the RETS 1.5 spec can be returned in the Capability URL List.
• Allows a Server to be capable of supporting multiple Metadata Versions simultaneously.

During the last 18 months it has been our experience that updating a Server's Metadata while at the same time preventing all Clients using that Server from breaking isn't as easy as it sounds. Currently the RETS 1.5 spec says all RETS Clients must check Metadata Version on Login and "This is the minimum version of the metadata that the host will support. If the version of the metadata being used by the client is less than this version the client MUST retrieve the newer metadata from the host."

While this seems logical the reality of the situation is most Clients don't check the Metadata Version on Login and most are not equipped to deal with Metadata changes on the fly. This has caused us a considerable amount of difficulty with Clients who are not updating their Metadata and adjusting their product accordingly. The position of the RETS Spec is very server-centric and we at Rapattoni Corporation think it should be more client-centric.

It would be highly beneficial if there was a way for a Client to provide a Metadata Version parameter on Login which basically says "This is my current Metadata Version, can you support me?" If the Server can support the Client's current Metadata Version then it will say "Yes I can support that version." or "No, this is the minimum version I support: ##.##.####."

At this point, if the Server says "Yes I can support that version.", the Client can continue initiating RETS Transactions with its current Metadata version meaning every aspect of the Server will function as if it were on that version. This functionality includes returning default queries of only those fields on that specific Metadata version. If the Server says "No, this is the minimum version I support: ##.##.####." then the Client knows it MUST get new Metadata and make adjustments accordingly.

We at Rapattoni Corporation think this will be a significant improvement to the RETS Spec and it will help prevent existing Clients from breaking when Metadata changes take place on the Server. Additionally, it will make it easier to update Metadata on the Server and keep it separate from older (but still valid) Metadata versions. Rapattoni Corporation upgrades its Internet MLS product quarterly and new fields are always becoming available. In order for the RETS Server Metadata to stay current, Metadata changes must be easy to make and most of all, not break any existing Clients.

‹RETS ReplyCode=20038 ReplyText=quoted-string › CRLF
‹MetadataVersion=##.##.#### ExpirationDate=YYYY-MM-DD /› CRLF
‹MinMetadataVersion=##.##.#### ExpirationDate=YYYY-MM-DD /› CRLF
‹/RETS› CRLF

This proposal adds an additional RETS Reply Code: 20038, Meaning: Metadata Version ##.##.#### is expired and cannot be supported. This proposal changes the way the Metadata Version Tags section on pg. 4-4 of the RETS 1.5 spec can be returned in the Capability URL List after Login. An ExpirationDate value MAY be supplied immediately after the (Min)MetadataVersion tags as shown below:

MetadataVersion=##.##.#### ExpirationDate=YYYY-MM-DD
MinMetadataVersion=##.##.#### ExpirationDate=YYYY-MM-DD

Since a Server can now be capable of supporting multiple Metadata Versions simultaneously, a Server MAY explicitly list ALL the Versions it currently supports in the Capability URL List along with their ExpirationDates (if applicable) in order to avoid any ambiguity. A MetadataVersion that has no ExpirationDate value means that version is not currently set to expire. Example:

MetadataVersion=01.50.4000
MetadataVersion=01.50.3011 ExpirationDate=2003-06-01
MetadataVersion=01.50.2050 ExpirationDate=2003-03-01
MinMetadataVersion=01.50.1000 ExpirationDate=2003-01-01

If a Server does choose to implement this proposal, it will need to keep track of different sets of Metadata internally and have built in functionality that allows it to switch between different Metadata versions on the fly. This can be accomplished by adding a Version column to the Metadata tables internally that donŐt already have it, and modifying the queries against the database to include this column in the WHERE clause.

It is also optional to include the ExpirationDate value after the MetadataVersion tag when the Server returns the Capability URL List after Login.