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

Peter Saint-Andre stpeter at jabber.org
Fri Jul 16 11:25:16 CDT 2004


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
> 


More information about the Council mailing list