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

Fletcher, Boyd C. J9C534 Boyd.Fletcher at je.jfcom.mil
Fri Jun 4 21:21:43 UTC 2004


> -----Original Message-----
> From: standards-jig-bounces at jabber.org 
> [mailto:standards-jig-bounces at jabber.org] On Behalf Of Ralph Meijer
> Sent: Friday, June 04, 2004 4:12 AM
> To: Jabber protocol discussion list
> Subject: Re: [Standards-JIG] Proposed Changes to JEP-60 - PubSub
> On Thu, Jun 03, 2004 at 10:22:19PM -0400, Fletcher, Boyd C. 
> J9C534 wrote:
> > 
> > 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:
> You've stated this multiple times, but clearly, as I observe 
> the nature of all replies, you still haven't made clear *why* 
> we /need/ to clarify the specification. You only name what 
> you want to see changed, but not how you came to that 
> conclusion. I can't see you string of thoughts.

the "why" is that the specification is too vague. I'm concerned that if the protocol specification has too many MAYs or ambiguities then you will get multiple incompatible non-interoperable implementaions. incompatible implementations are of little value to the community. We need a concise, consistent, non-ambiguous specification so that clients and servers using PubSub can RELIABLY know how the pubsub server will behave -- this is impossible with the current specification. 

> Let's go back to what you are working on. You said in one of 
> your later messages that you are implementing a whiteboarding 
> application using pubsub.
> First of all: cool! But then.
> > 1) hierarchy separator
> You say you think nodes ids should always be hierarchical. 

no. the PubSub server MUST support hierarchical nodes. the client or high level application protocol is not required to use them

> Why is that? In your application, how do you start using 
> pubsub? Who creates the node, and why is it important to have 
> it in a hierarchy? For Mimir, the nodes I create /look like/ 
> they are in a hierachy, but a the moment, that isn't really 
> important. For the avatar case, people disco a person's own 
> JID to discover the node id (and server) of its avatar pubsub 
> node. The avatar owner's client itself can just ask for an 
> instant node, as it doesn't really care about the name, just 
> that a node exists and that he nows the name so that he can 
> register it with the disco component.
> But if you do need hierachy in your nodes, how does the 
> client know how to get to the node. If you want to let the 
> client try the root of the hierarchy and drill down until he 
> finds what he is looking for, you can just use what is 
> described in section 8.1.10. You actually don't need to know 
> the hierarchy separator character, because you just get the 
> names of the children in the next disco.

except in in 8.1.10  you can't RELIABLY use disco because its NOT required. If node separators aren't required, then the original language in the specification about them must be removed as it serves no purpose. 

8.1.10: "A service MAY implement some kind of pubsub browsing mechanism which enables the user to discover various nodes. The user may then select nodes which he or she is interested in subscribing to. Entities SHOULD use the Service Discovery protocol for node discovery, subject to the recommendations in JEP-0030 regarding large result sets (for which Jabber Search [9] or some other protocol SHOULD be used). The examples show the protocol for possible results when using Service Discovery on a hierarchical pubsub service."

> If you need another way to determine the actual name of a 
> node, for example related to the owner's jid, you can't use a 
> generic pubsub service anymore, because now the node id has 
> semantics. If you were to store avatars like for example 
> 'avatars/ralphm at ik.nu', etc, you have to make sure that only 
> ralphm at ik.nu can create that node. Also, when the owner's jid 
> doesn't match the jid part of the node id anymore (transfer 
> of control), you have a problem.

ok. then the restriction I suggested on node and item IDs should be changed to say something like:

"NodeIDs and ItemIDs can only contain characters that are valid for JIDS."

> > 2) how notification works
> IMO, how notification works for a particular node, should be 
> stored in the node's configuration. We can standardize on the 
> names used for that as was suggested earlier. Adding new 
> attributes new attributes to <create/> is a useless 
> extension, since the JEP already allows to jointly create and 
> configure a new node. This is stated between examples 5 and 6 
> in section 8.1.1.

this just proves my point that it is ambiguous and poorly defined. this needs to be firmly defined in order for clients to depend on it.

> > 3) changing numerous SHOULDs to MUSTs
> The reason that there is a SHOULD instead of a MUST there 
> (and other places), is because I can think of many 
> applications where you really don't need node and 
> subscription configuration, and just want a simple, barebones 
> implementation of a pubsub service, possibly part of a bigger 
> system, where configuration like this is either hardcoded or 
> configured out-of-band. Areas where this applies includes 
> machine-to-machine communication between embedded systems. 
> People asked for this way back when we defined the 
> specification, as you can read in the archives. Actually, 
> subscription configuration wasn't even there in the beginning.

there is a difference between what the client implements and the server. The server implementation must be predictable to useful. Clients don't have to implement all server functionality. As an application developer you must be able to reliably know how the server will behave to an action. But the large number of SHOULDs and MAYs make that impossible.

> > 4) revamping of the itemID and nodeID naming
> I think the above at 1), applies here as well.
> > 5) specifying itemID & nodeID update behavior
> I think the above at 2), applies here as well.
> > 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.
> Sometimes, I don't need evolution to read my e-mail, and 
> mail(1) is sufficient an implementation. Don't assume 
> everybody needs a full-fletched pubsub service when this is 
> probably mostly not true. XMPP/Jabber is not only for IM 
> related stuff. People in this community also use it for 
> business applications (financial transactions, for example), 
> and don't actually need all the fancy stuff.

Again, I'm not talking about the client. it's the server. If your email server didn't fully support the core SMTP protocol you wouldn't have gotten the email so the client you use would have been irrelevant. 

> Again, if you still don't agree, come up with real, concrete 
> examples of implementations (in stead of just your 
> conclusions). You can use your whiteboarding app as a 
> starting point. Walk us through what you wanted to achieve 
> and why it didn't work like you desire. If you're concerned 
> about IPR issues, think up an analog problem with the same 
> properties and issues.

1) No clear, concise, non-ambiguous way to do updates to items and nodes
2) Explanation for notification does not explain how:

   a) Does a change in a child node cause a notification to be sent if the user is subscribed to only the parent node.
   b) Does a change in a parent node cause a notification to be sent if the user is subscribed to only the child node.  Is subscribing to a child node and not the parent even possible?
   c) What are te available options for configuring notification? 
   d) Are notifications sent out when a child node is created or deleted? 
   e) Does subscription of a parent node imply subscription to child node?

3) node hierarchy support is indeterminate. How do I know if the server supports node hieracharies?

4) in item 8.1.9 "Implementations of pubsub that choose to persist items MAY allow entities to request existing items from a node." -- MAY allow??? how does a client determine that without actually trying to get an item from node. Its things like this that are problematic.

5) in item 8.1.8 "Implementations SHOULD use the Data Forms protocol to accomplish this configuration." Well if I don't use Data Forms then how to you configure options...

More information about the Standards mailing list