| Organization: |
Falcon Technologies Corp |
| Name: |
Paul Stusiak |
| Email: |
pstusiak@gmail.com |
| Version: |
1.8.0 |
| Status: |
Adopted |
| Adopted Date: |
September 28, 2010 |
Synopsis
Different versions of StandardNames exist. This change proposal provides a method to express which version of StandardNames is used by a specific instance of a RETS server.
Rationale
Client vendors are not currently able to determine which set of StandardNames a specific instance of server has using the standard. This determination is currently done by contacting the operator and asking. This means that the client vendor cannot simply deploy their software and must manually configure the software to identify the version of the StandardNames that are used.
Proposal
The change proposal will add an optional body response line that will provide the version information of the set of StandardNames that this server uses. This will use the format described in RCP 65 - Session information tokens and described in Section 4.6, Login Response Body Format, response "OK" of the RETS 1.8.0 document.
A new section will be created and will read;
<new-text>
Section 4.7.5 Session Information Tokens
Add to Table 4-1 Well-Known Information Tokens
| StandardNamesVersion |
Character |
standard-names-version |
standard-names-version ::= 1*128TEXT CRLF
The standard-names-version indicates the date version of StandardNames that this system supports. A system is only expected to support a single version of the StandardNames and, in most cases, this will be the current version.
Server systems that do not provide this optional field make no representation about the version of StandardNames that they support, therefore, client applications should not assume any specific version of the StandardNames.
Server systems that do provide this optional field MUST return a value for the standard-names-version that matches one of the values from the Adopted StandardNames List from Real Estate Transaction Standard website.
The format of the standard-names-version is a string YYYY-MM where YYYY is the year of adoption and MM is the month of adoption. For example, a version of the StandardNames is 2010-04
</new-text>
Impact
No impact
Compatibility
Forward compatibility with 1.8 and higher versions of the Standard.
Comments (10)
Jun 03, 2010
Libor Viktorin says:
Since RCP 65 (Session Information Tokens) has already been adopted, the proposed...Since RCP 65 (Session Information Tokens) has already been adopted, the proposed info should be provided in the form of the info token:
Info = StandardNamesVersion; Date; full-date
The StandardNamesVersion token may be included as a well-known token in the table 4-1 proposed in RCP 65.
Jun 15, 2010
Steve Clarke says:
Agreed, and this was also discussed on the Standards Committee call. We should ...Agreed, and this was also discussed on the Standards Committee call. We should use the generic "Info=" tokens already adopted for the login response to represent the StandardName versioning scheme, and add StandardNamesVersion in the well-known tokens table as per RCP 65.
Jul 08, 2010
Paul Stusiak says:
This change proposal has been updated to reflect the "Info=" tokens pattern.This change proposal has been updated to reflect the "Info=" tokens pattern.
Jun 09, 2011
Paul Stusiak says:
Removed the "Modified Text" section of the change proposal that modified Section...Removed the "Modified Text" section of the change proposal that modified Section 4.6 since it was covered by RCP 65. In preparation for freezing the 1.8.0 document.
Aug 09, 2010
Libor Viktorin says:
Section 4.6 should not change. You should add the StandardNamesVersion to Table...Section 4.6 should not change.
You should add the StandardNamesVersion to Table 4-1.
Sep 27, 2010
Paul Stusiak says:
Updated to use Table 4-1Updated to use Table 4-1
Aug 19, 2010
Sergio Delrio says:
Suggestion: Can you allow for the server to support multiple different and concu...Suggestion: Can you allow for the server to support multiple different and concurrent versions of Standard Names. This would require that we allow multiple versions to be output and, additionally, a new Request argument to Search that would allow a client to request a specific version.
Aug 19, 2010
Rob Overman says:
I agree. Maybe a standard format for StandardNameVersion.I agree. Maybe a standard format for StandardNameVersion.
Sep 27, 2010
Paul Stusiak says:
I provided a version format example.I provided a version format example.
Sep 27, 2010
Paul Stusiak says:
That feels like another change proposal. I don't feel that I can add this to the...That feels like another change proposal. I don't feel that I can add this to the current proposal, although I would support a new change proposal with this change.