[Council] VOTE: JEP-0079 (Advanced Message Processing)
stpeter at jabber.org
Tue Jul 27 11:25:58 CDT 2004
Does this version address the Council concerns previously expressed?
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:
> 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
Jabber Software Foundation
More information about the Council