BEEP
Click on the red underlined text to get to the source
...
The TUNNEL profile provides a mechanism for cooperating BEEP peers to
form an application-layer tunnel ...
... destination. The term "proxy" is used to refer any
of the BEEP peers other than the initiator and the final destination.
...
...
In one use of this profile, a BEEP peer implementing the TUNNEL
profile is co-resident with a firewall. An initiating machine inside
...
... possible to use the TUNNEL profile to anonymize the true source of a
BEEP connection, in much the way a NAT translates IP addresses.
...
... proxy
machine does no further interpretation of the data. In particular,
it does not look for any BEEP framing. The two endpoint machines may
therefore negotiate TLS ...
... the service that "initial" wishes to access is called "final". The
examples also assume that the BEEP framework [2] is implemented on
...
... service and
finding the destination is not a BEEP server. (Of course, specifying
the telnet service ...
... Non-BEEP Example ...
... service and
accepting that the destination is not a BEEP server. The difference
at the protocol level is two-fold: The "initial" machine does not
include the innermost "tunnel ...
... element, and the final proxy
("proxy2") therefore does not expect a BEEP greeting.
initial proxy1 proxy2 final
...
... [5] After receiving the "ok" message, the "initial" peer can expect
raw, non-BEEP data to be sent to and received from the "final"
machine.
...
... element is examined. If it
has no attributes, then this peer is hosting the BEEP service that
the initiator ...
... channel zero, are implicitly closed.
o Any previously cached information about the BEEP session is
discarded.
...
... is responsible for determining the appropriate routing to reach a
peer serving the BEEP profile indicated by the URI in the attribute's
value. Rather than source routing ...
... profile" or "endpoint", then this peer is
the final BEEP hop. (This corresponds to "proxy2" in the "Non-BEEP"
example above.) In this case, as soon as the final underlying
...
... endpoint", then this peer is
the final BEEP hop. (This corresponds to "proxy2" in the "Non-BEEP"
example above.) In this case, as soon as the final underlying
transport connection ...
... session, and the tunneling of data starts. No BEEP
greeting (or indeed any data) from the final hop is expected.
Starting ...
... tunnel" element, and
the server that has been contacted does not offer a BEEP greeting, or
the BEEP greeting offered does not include the TUNNEL profile ...
... the server that has been contacted does not offer a BEEP greeting, or
the BEEP greeting offered does not include the TUNNEL profile, then
this too is treated as an error: the initiating transport connection ...
... tunnel" element, and the identified server is
contacted and offers a BEEP greeting including the TUNNEL profile,
then the outermost element ...
... TUNNEL profile is a profile of BEEP. In BEEP, transport
security, user authentication, and data exchange ...
... TUNNEL allows this connection between BEEP peers, and BEEP peers can
offer a range of services ...
... A.1 Registration: BEEP Profile ...