Specification - RETS

S ECTION
0LOGIN TRANSACTION
CHAPTER
A client MUST issue a login request prior to proceeding with any other request. The Login
transaction verifies all login information provided by the user and begins a RETS session.
Subsequent session control may be mediated by HTTP cookies or any other method,
though clients are required to support at least session control via HTTP cookies. Section
14 describes the session protocol in detail.
The server’s response to the Login transaction contains the information necessary for a
client to issue other requests. It includes URLs that may be used for other RETS requests,
and may also contain identity and parameter information if required by the functions
supported by the server.
4.1 Security
4.1.1 User Authentication
4.1.2 Client Authentication
4.1.3 Data Security
While this specification does not require the use of security — it is permissible, for
example, to operate a publicly-accessible RETS server — most operators of RETS servers
will wish to authenticate users. A server that requires that users be authenticated MAY
implement RFC 2617, HTTP Authentication. The use of at least digest authentication is
strongly recommended.
Client authentication may be performed through the use of the optional RETS-UA-
Authorization header (section 3.4). Prior versions of this specification used a speciallycalculated
cnonce value in the Authorization header to implement this function. A server
implementing this version of the RETS specification MUST accept the RETS-UA-
Authorization header for client authentication. It MAY accept RFC 2617-style
authentication as in prior versions of the RETS specification.
Needs for secure HTTP transactions cannot be met by authentication schemes. For those
needs, HTTP-over-TLS (commonly known as HTTPS) is a more appropriate protocol. A
Version 1.7.2 4-1