[Standards-JIG] Proposed Changes to JEP-60 - PubSub

Fletcher, Boyd C. J9C534 Boyd.Fletcher at je.jfcom.mil
Fri Jun 4 02:22:19 UTC 2004

we are still dancing around the fundamental issue, that the specification is not sufficiently defined. we need to clarify the specification in at least these areas:

1) hierarchy separator
2) how notification works
3) changing numerous SHOULDs to MUSTs
4) revamping of the itemID and nodeID naming 
5) specifying itemID & nodeID update behavior

JEP-68 and Disco don't apply to the above. I'm not suggesting adding new features that can be discovered or that even those above should be capable of being discovered. I consider them core functions. What should be discovered is something like whether the server supports persistence.


> -----Original Message-----
> From: standards-jig-bounces at jabber.org 
> [mailto:standards-jig-bounces at jabber.org] On Behalf Of Peter Millard
> Sent: Thursday, June 03, 2004 6:47 PM
> To: Jabber protocol discussion list
> Subject: Re: [Standards-JIG] Proposed Changes to JEP-60 - PubSub
> Joe Hildebrand wrote:
> > Is it possible that some of the tightening could take place using
> > JEP-68 registered field names in the node configuration form?
> Matthew A. Miller wrote:
> > That, and a set of pubsub-specific features (analagous to 
> what MUC defines)?
> Yes, this is exactly what I was saying.
> If an application requires a specific feature on a pubsub 
> server, it should do a disco#info and check the <feature> 
> elements. Once these are registered, it's all machine 
> readable. Combined with the JEP-68 field standardization, it 
> allows machines to also pre-configure nodes, etc.
> The obvious initial choices as has been pointed out are:
> - Hierarchy seperator
> - Allow items to be over-written?
> - etc..
> pgm.
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> https://jabberstudio.org/mailman/listinfo/standards-jig

More information about the Standards mailing list