[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..
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards