[Council] VOTE: JEP-0079 (Advanced Message Processing)
Matthew A. Miller
linuxwolf at outer-planes.net
Tue May 11 08:50:05 CDT 2004
Here are my responses to the wiki. I'll get the wiki updated with these
as time permits, and work with the JEP editor to make the appropriate
updates to JEP-0079.
Regarding Detail 1 ("Some error reporting text and examples should be
added..."): I'll add some examples to each condition and action. As
for processing, my initial thought was (as described in section 2.2:
"Server Processing") the server would validate all of the rules it was
given before trying to process them. If this seems too expensive, then
we can see what would work better, although I think fully validating
before processing would be more reliable.
Regarding Detail 2 ("If the <message/> is dispatched to another
server..."): The intent is that servers MUST NOT forward AMP-ed
messages to another server unless the recipient at understands AMP.
Requiring (not simply allowing) disco lookups every time is
unrealistic. However, I believe it is also unrealistic for an
AMP-supporting server to make assumptions that are too broad. Would it
be more acceptable to say something like the following?
Before forwarding a <message/> with AMP semantics to another server,
it MUST be aware of the receiving server's support for this
protocol.
This very well could mean that a server will need to perform a disco
request before it can forward the first AMP-ed <message/> to a
particular server it has no prior knowledge of.
[Somewhat OT: Maybe we need some form of "expiry flags" for disco info
and items? Better than assuming any cached disco info is valid
"indefinitely"...]
Regarding Detail 4 ("The expire-at condition will have a strange
interaction with..."): Yes, implementations are expected to garbage
collect expired messages, unless you have better ideas. If it doesn't,
then how can the system be reliable?
The expense of this depends on your implementation. One possible
implementation is to have a database of exiprable messages, which should
be significantly smaller than the entire message store. This task would
scan this database periodically (but frequently), and perform the
necessary actions for those messages that have expired, and flag it as
discardible. Then the next time an attempt would be made to deliver the
message (e.g. the user is now available), a scan of that same database
could be made, and it would actually be removed then.
Regarding Detail 5 ("6.3.2 Seems to imply no offline storage..."): The
intent is definitely not to prevent offline storage. That will be
clarified (any suggestions?).
Regarding Detail 6 ("6.3.3 is impossible over multiple hops."): The
point of expire-in is a TTL. Maybe the term used should have been
"live-for" or some such. Other TTL implementations I have seen did not
require synchronized clocks, provided the clocks ran at the same rate
(which I think is safe to assume here). It can be safely assumed (and
should be explicitly stated) the "base timestamp" for a particular hop
is the moment the message is received. Since the value MUST be adjusted
(decremented by the processing time), the "base timestamp" is adjusted
for each hop.
Using expire-at for something that is meant to track a short duration of
time seems even more problematic, it would definitely require clock
synchronization along the entire path.
If the resolution is unreasonable, then we can reduce that from
milliseconds to seconds. And as with "expire-at", such messages should
also be garbage collected.
Regarding Detail 7 ("Seems like it would be useful to have a partial
match..."): This had been discussed, and it was decided then that
either 1) it would enforce an "undocumented" interpretation of JID
resources that is not universally desirable, and/or 2) would introduce a
number of matching rules that may be too complex to handle in a timely
manner.
However, I am more than happy to have some form of partial matching
included.
Regarding Detail 8 ("In 6.3.4, if the value is 'other',..."): This is
correct. I had some (possibly irrational) problem having a condition
with only one option to it. Maybe "other" should just go away...
Regarding Detail 9 ("Possibly re-word this security consideration..."):
This will be updated.
Thanks,
- LW
More information about the Council
mailing list