RETS Meeting Notes: February 19-20, 2003


Search

A RETS working group meeting was held in Las Vegas on February 19-20. The first day was devoted to an interoperability event, with a marketing special-interest group meeting in the early afternoon. The second day was a RETS working group meeting.

Plugfest

The first RETS "plugfest" was a working session devoted to finding and fixing interoperability problems with the specification. The National Association of Realtors® (NAR) sponsored participation in this first day in order to further the ideal of having clients and servers interoperate "out of the box". The room was equipped with 20 LAN connections with a high-speed connection to the Internet, Wi-Fi networking, and a protocol analyzer. The objective was to gather the developers and tools in the same place, looking at the same diagnostics and viewing the same code.

A total of seven clients and eight servers (thirteen companies) participated, and by the end of the day, 45 out of the 56 possible combinations of client and server were tested and working. The process revealed the need for several clarifications in the protocol specification, and these will be posted in the next week or so. Some of the problems encountered had to do with problems with third-party vendor compliance with RFCs. These will be dealt with in a developer note.

The two biggest issues of the day both dealt with incorporated RFCs: RFC 2109 requires accepting and sending back multiple cookies, though this is not directly stated in the specification. In addition, RFC 2617 authentication has a backwards-compatibility provision that is not implemented by Microsoft's IIS. Other suggestions were the need to define the content of the "ID" field in multi-part GetObject responses, and the need for XML escaping of compact data; the latter issue was dealt with during the RETS working group meeting on the 20th.

The plugfest provided an opportunity to put the Avantia-developed compliance tester to work, looking for compliance issues in both clients and servers. These reports were forwarded to the document editor for use in clarifying sections of the specification. (One issue was also found with the compliance tester itself, which is fixed in the version linked to above.)

The plugfest also resulted in a number of developers meeting each other for the first time, and most agreed that the relationships formed will be at least as valuable in the coming months as the programming exercise. There was universal approval for holding another of these events.

Marketing Special Interest Group

During the afternoon of the Plugfest, Kevin McQueen led a meeting of the RETS Marketing special interest group. The group had a number of suggestions for marketing RETS and speeding its adoption.

One particular issue brought up during the working group meeting was summarized as "I'm RETS-compliant -- now what?" There needs to be a roadmap for someone who's adopted RETS to bring products to light. Other suggestions included trademarking the logo [in progress] and providing guidelines for its use on packaging.

Compliance Working Group

The group discussed the most useful immediate activities for the compliance workgroup to pursue, in light of the desire for some kind of formal compliance mechanism. The workgroup met after the main meeting; see the meeting notes for additional information. The first activity that will be pursued is a test protocol and list of compliance scripts for servers and sites, since this is the area where turnover is slowest and thus the need for compliance information is greatest.

Metadata Working Group

The metadata workgroup presented its omnibus metadata update proposal, which was approved with several amendments. First, both description fields are to be increased to 1024. Second, the size of ShortName is not to be changed from its current value. Finally, a usage note is to be added that the sizes are for storage management, not for the function.

Transport Working Group

The major topic of discussion was whether to put forward a version of RETS based on a standard transport/packaging scheme, or whether to stay with the existing scheme. There was strong opinion on both sides. The Transport Working Group is to publish a white paper on moving to a standard transport/packaging scheme.

One key issue was whether working on such a transition would inhibit new developers from adopting RETS until the standards-based transport scheme was adopted. There was no resolution on this.

The strongest argument for adoption was that the existing transport scheme requires more work to implement than one based on standards. The stand-pat group felt that this could be addressed with better packaging of the existing sample code and implementations. This should be done in any case.

One participant noted that while standards-based packaging toolkits are available for many platforms, they are much harder to obtain for older systems. For these systems, it would not be the case that switching to a standards-based packaging scheme such as SOAP would reduce time to adoption.

Data Dictionary Working Group

There was no data dictionary working group report since there were no submissions. One vendor asked how to submit the enhancements they wanted, and agreed to do so before the next meeting. These enhancements are primarily concerned with the transaction, rather than the MLS description of a property.

Intellectual Property

There was a brief discussion of the issue of intellectual property relative to RETS, and a short presentation on the work that MISMO has done on intellectual property. NAR has also done some work, and this will be presented at the next meeting. The primary issue is protecting the standard against submarine patents, which requires agreement by all participants in the meeting, conference calls and email discussions that the contributions to the discussion are either offered without royalty, or that the existence of a patent interest has been publicly disclosed.

Change Proposals

20. Special Search Token .ALL.

This proposal was adopted with two amendments. First, the token is changed to .ANY.. Second, as an implementation detail, the server is to treat this exactly as if the client had specified all possible values for the affected field. This means that the server can return a new error code, "Too complex", if it would have done so had the query listed all possible field values. The specific purpose for this amendment is to avoid requiring the server to process a query that is otherwise in violation of its query formulation parameters.

22. Clarification on Boolean data type

Adopted with two amendments. First, the interpretation of a Boolean item MAY (not MUST) be LookupMulti (not Lookup) in the table metadata. Second, if the interpretation is not specified, the client is free to display any accepted truth value (for example, 1 or 0, TRUE or FALSE, YES or NO).

23. Update MaxChoice

The proposal is adopted, together with a request for clarification on the use of MaxSelect.

25. Update Validation Flag

The proposal is adopted.

26. Update Response Body Format

There was an extended discussion on exactly how to select delimiters. The proposal finally adopted was that the Update Response body should follow the Compact data format in all particulars.

27. Special Search Token: .NULL.

The proposal was adopted with two amendments. First, the token is changed to .EMPTY. rather than .NULL.. Second, an implementation note is to be added such that the result of using this token is implementation-defined. The stated reason for the implementation note is that different systems may have different definitions of a null field. For example, some may not have a distinct null value for numeric fields; in this case, the server may choose to replace .EMPTY. with zero.
28. Omnibus metadata update

Adopted with amendments; see above.

29. Distributed data base enhancements

This proposal was discussed extensively, and many corner cases and ambiguities were found. The proposal requires a clear definition of "last modification date" -- which should really be a timestamp -- and also requires that a timestamp be sent from the server in order to imnplement this properly. The return code of "no longer matched" was deemed too difficult to implement, since it would require knowing what matched the last time, and reconstructing the record as it stood at an arbitrary point in time. A conference call was set up for interested participants to discuss the issue further.

30. Hotsheet

This proposal was discussed extensively and was found to have a number of the same issues as proposal #29. The proposal seems implementation-dependent, requiring a server to keep a resource that could be labeled "hot sheet". In addition, the definition of a hot sheet varies extensively from MLS to MLS. This will also be discussed in the conference call for distributed data base modifications, since some of the same issues are involved.

Other Issues

There was a call to improve the archiving system for the RETS mailing lists. This will be done. In addition, it was noted that the UPDATE_HELP metadata was missing from the figure in Section 11 of the transaction specification document.

The issue of XML-escaping was discussed extensively. The final resolution is that a change proposal is to be issued that formally requires XML-escaping of all request and response bodies, together with a flag that can be sent to a server to specifically request that COMPACT data not be XML-escaped. This was chosen because of the directive that in RETS 1.5, all request and response bodies were to be well-formed XML. This can't be the case without the use of XML escaping.

Next Meeting

Participants felt that, between the issues raised with change proposals 29 and 30, and the compliance issues that were raised, a six-month period was too long to wait. Participants agreed that selecting a date during the week of April 28 would be the best compromise. This is being set up and an exact date and location will be announced shortly.