Specification - RETS

More documents

Recommendations

Info

3.1.3 Response Bodies 3.2 Request Format The body of a response to most RETS requests is a well-formed XML document; the exceptions are the Get transaction (section 8) and the GetObject transaction (section 5). This means that servers must construct the body in accordance with the XML specification [17], and that clients must parse the body in accordance with that specification. A RETS request is either an HTTP GET request or an HTTP POST request. In the case of the GET-request the Argument-List is appended to the Request-URI after a delimiting question mark (“?”). For the post-request the Argument-List is sent as the first entity body for the POST method. get-request ::=GET⋅Request-URI [ ? Argument-List] ⋅HTTP-Version CRLF *message-header CRLF post-request ::=POST⋅Request-URI ⋅ HTTP-VersionCRLF *message-header CRLF [Argument-List] The Request-URI, HTTP-Version and message-header are defined in RFC 2616. The detailed construction of the Argument-List defined in HTML 4.01. 3.3 Required Client Request Header Fields The HTTP header of any messages sent from the client MUST contain the following header fields: User-Agent This header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations, as well as providing enhanced capabilities to some user-agents. All client requests MUST include this field. This is a standard HTTP header field as defined in RFC 2616. User-Agent ::= User-Agent: 1* product product ::= TOKEN [/ product-version] product-version ::= Example: TOKEN User-Agent: CMAZilla/4.00 Product tokens should be short and to the point: use of them for advertising or other nonessential information is explicitly forbidden. Although any token character may appear in a product-version, this token SHOULD only be used for a version identifier (i.e., successive versions of the same product SHOULD only differ in the product-version portion of the product value). For more information about User-Agent see RFC 2616. 3-2 Real Estate Transaction Specification Version 1.7.2
A server MAY advertise additional capabilities based on the client application User-Agent, and MAY refuse to proceed with the authorization if an acceptable User-Agent has not been supplied. A server MAY also choose to authenticate the client application identity cryptographically using the RETS-UA-Authorization header; see section 3.4 for additional information. RETS-Version Cookie The client MUST send the RETS-Version. The convention used is a “..” numbering scheme similar to the HTTP Version in Section 3.1 of RFC 2616. The version of a RETS message is indicated by a RETS-Version field in the header of the message. The client MUST implement cookie handling as specified in RFC 2109. If any server response has included a valid Set-Cookie header, and the cookie in that header has not expired, the client MUST return the corresponding Cookie header. See RFC 2109 for the full specification. 3.4 Optional Client Request Header Fields Authorization Authorization header field as defined in RFC 2617. See 4.1, “Security”, as well as RFC 2617, for additional information. RETS-Request-ID RETS-Request-ID ::= Accept-Encoding Accept-Encoding ::= A character string of printable characters which the client can use to identify this request. The contents are implementationdefined. If this field is included in a request from the client then the server MUST return it in the response. 1*64ALPHANUM A comma-separated list of MIME types indicating the content encoding schemes that the client is willing to accept. This is intended to support the use of compression in data returns; see section 3.8 for additional information. 1*64ALPHANUM/1*64ALPHANUM *[,1*64ALPHANUM/ 1*64ALPHANUM…] RETS-UA-Authorization A client MAY support authentication of its User-Agent value by including the RETS-UA-Authorization header. Servers MAY require this header with a valid value before providing services. RETS-UA-Authorization::= ua-method ua-digest-response ua-method::= Digest ua-digest-response::="*LHEX " See section 3.10 for the method of computing the ua-digestresponse value. The client MAY send this header under any circumstances. It need not send this header if the server has not indicated that it Version 1.7.2 3-3
Page 1: Real Estate Data Interchange Standa
Page 4 and 5: Required Response Arguments . . . .
Page 6 and 7: iv Real Estate Transaction Specific
Page 8 and 9: vi Real Estate Transaction Specific
Page 10 and 11: viii Real Estate Transaction Specif
Page 12 and 13: SHOULD This word or the adjective
Page 14 and 15: 1-4 Real Estate Transaction Specifi
Page 16 and 17: 2.3 Rules The following rules are u
Page 18 and 19: Note TEXT ::= Implementers are cau
Page 20 and 21: |"25" %x30-35 ; 250-255 reg-name ::
Page 24 and 25: 3.5 Response Format requires user-a
Page 26 and 27: Example: Content-Type Example: RETS
Page 28 and 29: 3.9 General Status Codes Any of the
Page 30 and 31: 3-10 Real Estate Transaction Specif
Page 32 and 33: compliant server MAY support only H
Page 34 and 35: oker-code ::= 1*24ALPHANUM 4.7.2 Me
Page 36 and 37: 4.8.3 Office List Information passw
Page 38 and 39: 4.11 Reply Codes section 5.1.1) for
Page 40 and 41: The qvalue is used to specify the d
Page 42 and 43: Object-ID The object number being r
Page 44 and 45: --simple boundary-- 5.11.2 Error Ha
Page 48 and 49: that users would read or see the me
Page 50 and 51: 7.2 Search Terminology 7.2.1 Field
Page 52 and 53: If the client requests STANDARD-XML
Page 54 and 55: 7.4.7 StandardNames This would mean
Page 56 and 57: 7.7 Query language 7.7.1 Query lang
Page 58 and 59: 7.7.3 Sub-queries the same as 2 or
Page 64 and 65: 9.5 Reply Codes 9.6 Encryption Key
Page 66 and 67: database is not updated. If this en
Page 68 and 69: 10.5.2 Warning block 10.6 Validatio
Page 72 and 73:
System Resource Class Table Foreign
Page 74 and 75:
corresponds to the similarly-positi
Page 76 and 77:
Table 11-4 Well-Known Resource Name
Page 78 and 79:
11.2.3 Foreign Keys Table 11-6 Meta
Page 80 and 81:
Table 11-8 Metadata Content: Foreig
Page 82 and 83:
COMPACT header tag: METADATA-TABLE
Page 84 and 85:
Table 11-12 Metadata Content - Tabl
Page 86 and 87:
11.3.3 Update A given data resource
Page 88 and 89:
11.4 Metadata Format for Shared Ele
Page 90 and 91:
COMPACT header tag: METADATA-LOOKUP
Page 92 and 93:
11.4.6 Update Help RETS Regular Exp
Page 94 and 95:
Table 11-32 Metadata Content: Valid
Page 96 and 97:
during expression evaluation, field
Page 98 and 99:
COMPACT header tag: METADATA-VALIDA
Page 100 and 101:
11-30 Real Estate Transaction Speci
Page 102 and 103:
“COMPACT” means a table descrip
Page 104 and 105:
Table 12-1 GetMetadata Reply Codes
Page 106 and 107:
13.3 Multivalued Fields COMPACT for
Page 108 and 109:
14.3 Session 14.4 Termination then
Page 110 and 111:
NOTE RETS 1.7.2 requires all serve
Page 112 and 113:
15-4 Real Estate Transaction Specif
Page 114 and 115:
Stuart Schuessler Libor Viktorin Ma
Page 116 and 117:
17-2 Real Estate Transaction Specif
Page 118 and 119:
[15] Kristol, D. and Montulli, L.,
Page 120 and 121:
Table A-1 DTD References RETS Metad
Page 122 and 123:
B.3 Foreign Keys B.4 Class 2002-03-
Page 124 and 125:
Type: METADATA-UPDATE_TYPE ID: Prop
Page 126 and 127:
B.14 Validation Lookup →UpdateHe
Page 128 and 129:
B-8 Real Estate Transaction Specifi
Page 130 and 131:
Table C-1 Consolidated list of RETS
Page 132 and 133:
Table C-1 Consolidated list of RETS
Page 134 and 135:
D.2 Datatype Character Interpretati
Page 136 and 137:
E-2 Real Estate Transaction Specifi
Page 138 and 139:
IOC-2 Real Estate Transaction Speci
Page 140 and 141:
J Justification, text, specifying,
Page 142:
IX-4 Real Estate Transaction Specif
show all

Specification - RETS

Create successful ePaper yourself

Delete template?

Save as template?