client
Click on the red underlined text to get to the source
... tags should be specific enough that finding a known pair
(e.g., "RetMail:POP3" would be sufficient for a client to identify a
server with which it can communicate.
...
... Starting with the first sorted NAPTR record, the client examines the
SERVICE field to find a match. In the case of the S-NAPTR ...
... terminal lookup and server contact.
That is, a client must backtrack and attempt other resolution paths
in the case of failure.
...
... service exists. If bunyip.example
has no "WP:Whois++" NAPTR record, the application client MUST
backtrack and try the next available "WP:Whois++" option from
example.com. As there is none, the whole resolution fails.
...
... example.com. As there is none, the whole resolution fails.
An application client first queries for the NAPTR RRs ...
... Clients Supporting Multiple Protocols ...
...
In the case of an application client that supports more than one
protocol for a given application service, it MUST pursue S-NAPTR ...
... protocol.
That is, the client MUST NOT start looking for one protocol, observe
that a successive NAPTR ...
... NAPTR RR standard. A DDDS application is a client use convention.
The rest of this section outlines the specific elements ...
... behaviour for interacting with the servers that are reached via S-
NAPTR. Specifically, under what circumstances should the client
retry a target that was found via S-NAPTR ...
... preference ranking.
For example, if the client gets a "connection refused" message from a
server, should it retry for some (protocol-dependent) period of time?
...
... identify the mechanics of the expected identification handshake when
the client connects to a server found through S-NAPTR.
...
... tree to use only
those records referring to application protocols supported by the
client, the tree could be quite deep, and retracing the tree to retry
...
... Guidelines for Client Software Writers ...
... up as described in Section 4.2 and had the extensible messaging
service set up as described in Section 4.4, then a client querying
for the NAPTR RR ...
... )
Sorting them by increasing "ORDER", the client would look through the
SERVICE strings to determine whether there was a NAPTR ...
... service it was looking for, with an
application protocol it could use. The client would use the first
(lowest PREF) record that matched to continue.
...
...
Consider the example in section 4.3. Visually, the sequence of steps
required for the client to reach the final server for a "ProtB"
service for EM for the thinkingcat.example domain ...
... NAPTR record matches the desired criteria; it has an
"s" flag and a replacement fields of "_ProtB._tcp.example.com".
So the client looks up SRV records for that target, ultimately
...
... SRV records listed in Section 4.3.
5. The client attempts to reach the server with the lowest PREF in
the SRV list -- looking up the A record ...
... machine!
7. The client attempts to reach the second server in the SRV list
and looks up the A record ...
... 10. The server responds with an "OK" message.
11. The client uses ProtB to challenge that this server has
credentials to operate the service ...
... domain names to
identify server targets and stipulate that clients should look up SRV
resource records ...
... secondaries).
o It can be moved from time to time without disrupting clients'
access, etc.
...
... REGEXP field of NAPTR. These restrictions make the client's
resolution process much more predictable and efficient than it would
...
...
The expected output of this Application is the information necessary
for a client to connect to authoritative server(s) (host, port,
...
... A records in the Additional
Information portion of the DNS packet. Clients are encouraged to
check for additional information but are not required to do so. See
the Additional Information Processing section of [5 ...
... NAPTR and SRV records could be inserted to
redirect clients to unintended destinations. This problem is hardly
unique to S-NAPTR ...
...
1. During some portion of the protocol handshake, the client sends to
the server the original name of the desired destination (i.e., no
...
... TLS extension.
2. The server sends back to the client a credential with the
appropriate name. For X.509 certificates ...
... semantics defined by the application protocol,
the client compares the name in the credential with the name sent
to the server.
...
... reasonable assurance that the correct end point has been reached.
5. The client and server establish an integrity-protected channel.
...
...
Assuming the client supports 1 protocol for a particular application
service, the following pseudocode ...
... pseudocode outlines the expected process to
find the first (best) target for the client, using S-NAPTR.
...
... (connection refused, application-level error), the client is expected
to try the next host-port ...
... S-NAPTR tree it finished.
Therefore, client software writers could
o entwine the application-specific ...