Hi, Jim, All!

> fb_dpb_ip_path <total length> <count byte> <ip address list>

I implemented this piece in my tree some time ago to support Trace API
functionality.
The difference of implementation is that IPv4 is not the only protocol
supported by the design.
IPv6 address is longer, SSL certificate header is much longer.

IPv4 addresses can almost always be forged and in many cases cannot be
trusted for security purposes.

Repeating structure in mentioned block (isc_dpb_address_path) is
consisted of protocol identifier, address block length and address block
containing protocol-specific address in human-readable form suitable for
matching.

regexp is used for all string pattern matching functionality in Trace
API at the moment.

> where "ip_address_list" is an ordered list of ip addresses,
> each expressed as 4 byte binary integer in "vax" format. The
> fb_dpb_ip_path parameter would be created and managed by the
> remote server component, ordered by by reverse distance from
> the server, i.e. closed connection first. The remote server
> would either append the parameter to a given dpb without a
> fb_dpb_ip_path parameter, or rewrite a dpb with an
> fb_dpb_ip_path parameter so that it's client's ip address
> would appear as the first ip address. [Note: only the first
> ip address can be consider reliable for security purposes.]

> I recommend that the user management SQL commands and
> fb_update_acount_info be implemented in Firebird 2.0, with
> fb_dpb_ip_path be deferred to Firebird 3.0.
>

> Jim Starkey

Nickolay