[Council] VOTE: JEP-0079 (Advanced Message Processing)

[Matthew A. Miller]

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