[Council] JEP-0079?

Peter Millard me at pgmillard.com
Tue Aug 31 15:40:18 CDT 2004


Peter Saint-Andre wrote:
|| Matt Miller and I have published a new version that clarifies a few
|| points in the spec. The changes are mainly to the explanatory paragraphs
|| at the beginning of the following sections (also, the expire-at time is
|| now required to be a UTC DateTime):
||
|| http://www.jabber.org/~stpeter/jeps/79.html#conditions-def-expireat
|| http://www.jabber.org/~stpeter/jeps/79.html#conditions-def-expirein
||
|| Mr. Millard, what say you?

My vote is still -1 for two reasons:

(1) Section 2.2.4 says "A server MUST NOT dispatch a <messge/> stanza with AMP
semantics to another server unless it knows that the next server supports AMP...
The problem with this text is that it means that we eliminate the possibility
for 'dumb-relays' to be introduced into the jabber network. Consider the
following example:

psa at jabber.org sends a message to pgm at jabber.com. In the middle of these two
servers is a dumb relay for whatever reason (firewall traversal, etc..) The
message would traverse the network like this:

psa at jabber.org  ---> Server A ---> Dumb-Relay --> Server B ---> pgm at jabber.com

Given this network layout... nother prevents this message from traversing the
network normally, but with AMP turned on, I can no longer send the message. This
seems bad :) What I propose is that the sender (psa at jabber.org in this case)
should be resposible for disco'ing the recipient's server (Server B in the
diagram) to ensure that the recipient's server supports AMP. The intermediate
hops are irrellevant. Note that this doesn't preclude the use of "smart-relays"
which have knowledge about AMP and may choose to expire messages as they
traverse the network. This also allows the client to adapt it's GUI based on the
recipients server.

Some text could easily be added to section 2.1.1 (Discovery) to force this to
happen. I'd say something like:

"The sender MUST discover whether or not AMP is supported by the recipient's
server by sending a disco#info query to that server. These results may be cached
for future use."

(2) I still have serious issues with the whole "expire-in" condition. The
expire-at condition has plausable and common use cases, like: "Mountain man is
in the office", which you want to expire in 10 minutes. The client is easily
capable of determining what the UTC timestamp is for NOW + 10 minutes, and can
plunk the expire-at condition on the message.

If I used an expire-in condition for this message, and the message needs to
travel across multiple servers, there is no way that the second server can take
into account network transmission time. Given normal TCP retry timeout periods,
the message may be delivered by the TCP stack AFTER it was supposed to timeout.
However, because there is no concrete timestamp for this, the second server sees
that it still has 599 seconds (because the originating server deliver the
message to it's s2s component in 1 second) to process the message. In reality,
the message has taken 605 seconds to arrive at the new server from the s2s
component.

I see absolutely no advantage in having two different expire-at/in conditions,
when in reality, we only need expire-at. Make the sender of the message
calculate the actual UTC time to have the message expire in, and send it off.
This seems like a much simpler and elegant way to go.

pgm.



More information about the Council mailing list