The problem in this case is that there are several elements required by the DTD, and if these are not included in the Select argument, the only choice would be to produce a document that would not validate. The group agreed that the server should augment the Select list with all of the required elements, as if the client had included them. The group agreed that the DTD should be revised, if necessary, to reduce the number of required elements to an absolute minimum. This was adopted 14-2.

The other ambiguous case was a query which specifies StandardNames=0 for the query namespace, and Output=STANDARD-XML. There was considerable rancor as to how to handle this, with some people thinking that it should be an error, some thinking that the selection should be specified using system names, and some (well, at least your reporter) thinking that the selection should be interpreted as standard names. The issue was punted to the Metadata workgroup.

Another request was for the ability to specify a site-specific or perhaps a second standard DTD for output. The suggestion was for additional values to be added to Output=: CUSTOM-XML, with a specific DTD appended, or SYSTEM-NAME-XML-SO-ITS-REALLY-CLEAR to specify a site-specific DTD in system name terms.

Eric Schlosser is developing a client that is designed to use StandardNames exclusively. He agreed to work with Paul Stusiak to do a test on MRIS's system and report back with his experiences.

Proposal 34: Optional RETS-Server Response Header

Amended so that the format of the RETS-Server token is in the same format as recommended in RFC 2616. Passed without dissent.

Proposal 35: Field Data Encoding

Passed with three amendments: first, the document will specify that the characters percent (hex 25), plus (hex 2B) and the field delimiter MUST be escaped. An amendment to add characters in the range hex 00 to hex 1f, plus hex 7f, passed 14-2. A further amendment to escape all octets with a value of hex 80 or higher failed 10-9. All other RFC 2396 escaping MAY be performed. Decoding MUST be in accordance with RFC 2396. Second, the tagging scheme is amended to allow row-by-row selection of the encoding scheme, such that each <DATA> element may contain a decode attribute, which overrides the attribute value in the <DELIMITER> element. Finally, the value "none" is allowed for the value of the decode attribute in either location.

Several suggestions involving XML-encoding were made but rejected for performance and data expansion reasons.

Proposal 36: Client Software Validation

Adopted unanimously, with minor alterations.

The proposal was modified by the group to so that the digest response was split into two parts:

a1 = <MD5(product ":" User-Agent-Password)>
ua-digest-response = <MD5(HEX(a1) ":" RETS-request-ID ":" session-id ":" rets-version-info)>

This was done so as to allow precomputation of the hash containing the password, thus avoiding the need to store the password itself. The wording in the specification change should note that the client is required to send the header only if the server responds to a transaction with a 20037 RETS error code.

Three additional change proposals came in too late for formal consideration, but were discussed briefly.

Proposal 37: Validation Expressions

Mark Lesswing, of NAR's Center for Realtor Technology, provided a demonstration of JavaScript-based field validation, along with information about pre-existing implementations of JavaScript that are available. Several minor problems were noted with the change proposal as it stands, and Mark will fix these and submit an updated proposal.

Proposal 38: Field Security Metadata

Bruce Toback withdrew this from consideration at the current meeting.

Proposal 39: GetObject Numbering

After some discussion, the group asked for a competing change proposal that would add a Preferred flag to the data returned from GetObject. 11 members preferred this approach, as opposed to nine preferring the renumbering approach in the existing change proposal.

The license agreement was examined, and left largely intact except that (a) a definition of the term "Product" is required, and (b) the time for fixing a problem is extended from 30 to 60 days. This was done to insure that there was adequate time to get through QA cycles, release procedures and other internal processes.

The group discussed the possibility of adding new test scripts. Areas that were offered included additional DMQL testing, dynamic query builds, verification of deep parameters such as Offset, negative testing, and search result validation. Dynamic query builds were placed higher on the list, since they would enable more automation of the test process.

The final issue was the process for adding new scripts, given that logo licensees agree to pass those scripts even if there is no requirement for formal recertification. The agreed procedure was that the new test would be submitted to the compliance workgroup for an email vote. An 80% affirmative vote is required to accept the test, but the decision criteria are limited to whether a given test in fact confirms an unambiguous requirement that's already in the specification. The voting requirement was to insure that the specification couldn't be reinterpreted by introduction of a new test.

If there is an interpretation issue, the full RETS Working Group can override the acceptance of the test (and, presumably, would act to clarify the language in the specification as well).

Note: Marketing and Media Management notes will be posted as soon as they are received.