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

Peter Saint-Andre stpeter at jabber.org
Tue Jul 27 11:25:58 CDT 2004


Does this version address the Council concerns previously expressed?

Peter

On Fri, Jul 16, 2004 at 11:25:16AM -0500, Peter Saint-Andre wrote:
> Matt and I have updated JEP-0079 to address the concerns expressed.
> 
> Please review version 0.10 and let the author / editor know if there are
> outstanding concerns:
> 
> http://www.jabber.org/jeps/jep-0079.html
> 
> Thanks.
> 
> Peter
> 
> On Tue, May 11, 2004 at 07:50:05AM -0600, Matthew A. Miller wrote:
> > 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
> > _______________________________________________
> > Council mailing list
> > Council at jabber.org
> > https://jabberstudio.org/mailman/listinfo/council
> > 
> _______________________________________________
> Council mailing list
> Council at jabber.org
> https://jabberstudio.org/mailman/listinfo/council
> 

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.php



More information about the Council mailing list