[edit]
Message Session Relay Protocol
when reading draft-ietf-simple-msrp-relays-02.txt
by Jennings & Mahy expired in April 2005 ...
advantages of PSYC/MMP over MSRP relays for our purposes:
+ MMP doesn't need to specify all hops. thus:
+ more privacy
+ less overhead (vs more state)
+ the involved nodes decide upon routing/relaying, not the client
+ MSRP is not suited for chat/conferencing:
+ providing a list of recipients and even their relays doesn't scale
+ this approach defeats multicasting whereas
+ MMP comes with contexts
+ MSRP cannot operate without TLS between relays ("interserver")
+ PSYC/MMP is real, MSRP relays are just a draft
but that doesn't mean we can't be inspired by it..
ideas for PSYC/MMP from SIMPLE and MSRP:
+ use the _tag for {tag and }tag packet delimiters instead of .
+ use ------ because it allows to check every 6th byte when seeking
+ no, better use { and }, {{ and }} or {{{{{ and }}}}}
depending on size of outgoing data and we cannot provide length
+ then again, according to [[libpsyc]] evaluating length is faster
than any scanning strategy with funny delimiter characters
+ use presence of _tag as indicator for receipt-report-echoes.
any packet containing _tag_reply is a valid report echo
(see Report-Failure in MSRP).
+ without _tag the message does not need reporting/echoing,
only the regular applicative echoing as for _message and
_request is done
? we could run timers to report every single message not making
it to the next hop, but aren't single reports nicer anyway?
+ "Responses can only be sent over existing connections."
interesting detail
? _fragment repacking: the draft suggests using smaller fragment
sizes and instead sending multiple fragments at once (0-3, 4-7..)
which the relay can repack into smaller or bigger packets
(bigger: 0-7, 8-14..), (smaller: 0-1, 2-3, 4-5..).
cute! would we want this or is it just extra complexity?
+ _notice_link_start after _request_link should provide all the
URLs which are now available as identification/routing means
to the linked client (MSRP: Use-Path) instead of having to look
them up in a self-/x
+ integrity awareness:
when doing auth or other operations, be aware if integrity needs
to be taken care of (hashing) etc or is unneeded because the circuit
is encrypted anyway. they say "Note: Only auth, not auth-int is
needed because TLS provides integrity."
+ we never needed it, but providing min-expires and max-expires for
_expires headers is cute:
"423 Interval Out-of-bounds. Max-Expires header."
+ clients should support multiple identities
(For example, some organizations could deploy an "intra-org"
relay and an "extra-org" relay.)
+ MSRP allows for AUTH to go thru client->intranet->extranet->...
PSYC can do the equivalent by sending a _request_link from the
intranet UNI to the extranet UNI, if anyone cares to code it.
? stateless UNI servers are feasible, but not desired. you may want
psyc servers that share the same DNS name, then instead of logging
in once you could have creds going to the server at every message,
or the server creates a token which authenticates you to all other
servers, so you have to send it to them at every request. this is
all feasible, but it makes the servers dumber than we like them to.
psyc prefers load distribution by redirecting the single DNS name
to a set of subnames, then have a full fledged stateful psyc server
respond from there. the receiving servers just need a way to map
the users to their respective final home server. like all nicknames
starting with "x" are directed to "x.example.org" - neither clients
nor talking partners need to know of this in advance, a redirect
will tell them.
? session counting in circuits: MSRP counts the amount of sessions
that are using a tcp circuit to a remote node and only dismantles
the circuit if the sessions have been shut down and a timeout has
expired. sounds like too much work just to clean out a socket?
doing it the jabber way (dismantling active circuits carelessly
of sessions after a too short period) isn't an option either.
* the PSYC way is to keep circuits running until they remained idle
for a seriously long time. after all "sessions" in psyc do not
imply that something will happen over that line within the next 24h.
it might just be a friendship context which is established forever
and still the friend hardly ever logs in.
"Relays should keep connection open as long as possible. If a
connection has not been used in a significant time (many minutes) it
could be closed. If the relay runs out of resource and must close
connections, it should first stop accepting new connections from
clients then start closing connections on a least recently used
basis." (5.2.7 Managing Connections)
so we are not the only ones promoting the idea of keeping sockets
running as long as possible. but since our servers aren't stateless
we cannot reject our users. we need to shutdown unused circuits
first, but we can additionally redirect unregistered users, which
also avoids new registrations. if for some crazy reason all
registered users decide to go online at once we still have the options
of (a) doing all outside communication through one relay, (b) switch
as much as possible to UDP, (c) even redirect registered users
elsewhere, then forward incoming messages for them over there.
? MSRP always provides port numbers in uniforms, so whenever the port
number is missing, this means a SRV is supposed to be made. cute.
since we have extended the uniform syntax by :#c and :#d for tcp
and udp ports, why might as well use :s to mean "look it up by SRV"
and :#e for encrypted circuits (TLS). so the default meaning of a
uniform is still to use the default port by either TCP or UDP, but
by adding :s you get all the nifty miracles and tricks of SRV. how
do we do about identity checks? i mean :#c and :#d are legitimate
parts of a UNI if changing those could mean ending up on a different
entity. but what about :s after resolution? can you just go ahead
and change it into the resulting :#c or :#d within the uniform? or
do you leave the :s in the uniform but remember what :s resolved to?
? what is message/cpim? oh, it's new:
Klyne, G. and D. Atkins, "Common Presence and Instant Messaging
(CPIM): Message Format", RFC 3862, August 2004.