[standards-jig] JEP-0060 comments

Russell Davis rkdavis at burninghorse.com
Wed Jan 22 00:45:37 UTC 2003

just for completness and well because we can I think the errorcodes
table should also contain error codes 402 (Payment Required) and
possibly 407 (Registration Required)

certainly not much use at the moment but I notice that some of the
suggested uses for pubsub are things that could require payment (micro
or otherwise) and/or registration.


On Thu, 2003-01-02 at 15:36, Peter Millard wrote:
> Greg Hewgill wrote:
> > I've been working on an implementation of the publish-subscribe
> > protocol as proposed in JEP-0060. I've got most of an implementation
> > working, with the exception of some owner use cases. While working on
> > this, I came across many things in JEP-0060 that probably need
> > clarification.
> Excellent!! Its great to see that someone has started an implementation to
> help work these issues out. My comments are inline below. Note that I'm
> currently working on the JEP again as things at work have slowed a little
> over the holidays, I'm hoping to get this ship-shape soon. If others have
> issues/comments please make them!
> > - The use of a full JID versus the base JID is unclear. Example 13/14
> > shows   sub1 at foo.com/home subscribing to a node, and the server
> > replies with   jid="sub1 at foo.com". When items are published to this
> > node, do the <message/>   elements go to "sub1 at foo.com" or
> > sub1 at foo.com/home?
> Yes, this is an issue that I'm trying to address. A few things I'm putting
> into the next draft:
> * Added a jid attribute to the subscription element when subscribing:
> <iq type="set" from="sub1 at foo.com/home" to="pubsub.jabber.org" id="sub1">
>   <pubsub xmlns="http://jabber.org/protocol/pubsub">
>     <subscribe node="generic/pgm-mp3-player" jid="sub1 at foo.com"/>
>   </pubsub>
> </iq>
> Note that for iq transactions, the server must send back TO the full jid,
> since JSM will not route iq packets which do not have a resource.
> * Adding notes relating to the server may choose to validate that the
> requesting jid is "allowed" to subscribe on behalf of the requested jid. IE,
> I may have another component (proxy.foo.com) which is allowed to subscribe
> any JID.. Otherwise, the jid in the <subscribe> element must match the bare
> jid in the "from" attribute
> > - What are the semantics of item id attributes? Should they be unique
> > within a   node? The examples show id="current" being used, but does
> > this mean the new   item replaces the existing item with id
> > 'current', or does it create a new   items with that id?
> I would think the ID's should be unique for a given node. If someone
> publishes with the same node, and implementation may over-write the old
> item, or give an error?
> > - Should entity presence control whether publish notifications are
> > sent? This   is mentioned in JEP-0024 section 3.4 (Delivery
> > Sensitivity), and seems like a   good idea (as long as it's optional).
> This should be an optional configuration piece. I've added this option to
> the config example. If an implementation wishes to use presence to base
> deliver, then the pubsub component MUST subscribe to that users presence. I
> may put an example into the JEP about this, since I'd like to see <x> tags
> being used in these subscription requests so that clients can "auto-allow"
> these.
> > - Should entities be permitted to unsubscribe themselves while still
> > in the   Pending state? Table 2 shows that the only way out of the
> > Pending state is by   Owner action.
> Yes, absolutely, this was an over-sight in the current draft. I will fix up
> the state chart. This should work just like normal presence susbcriptions.
> If I'm currently pending, then an unsubscribe should make my new affiliation
> be none, and remove me from the pending list.
> > - There needs to be some way for a node owner to retrieve Pending
> > subscribers.   Right now the only thing the owner can do, if a
> > subscription request is   missed, is to check the complete node-
> > entity affiliation list (example 43)   and look for those in state
> > Pending. Even so, there is no way to retrieve the   <thread/> value
> > from this.
> I've added this to the latest draft. Basically, the node-owner would send
> in:
> <message from="node-owner" to="pubsub.jabber.org">
>     <x xmlns="http://jabber.org/protocol/pubsub#owner"
>        action="get-pending"/>
> </message>
> The component would respond by sending all of the messages again to the
> user.
> [Stuff about <thread/> munched]
> Yes, the <thread> element was old and can safely be removed. I've done so
> from the current draft. The subscriber and owner should ge the appropriate
> packets back, and have sufficient information to get context. Typically the
> <thread> would be used in x-data message exchanges to give the user some
> context, but this is not required in this application.
> > - If there is more than one entity with an Owner affiliation to a
> > node, who   gets the subscription authorization requests. The node
> > creator? A designated   approver? All owners?
> I think this should be up to the implementation. I need to add some notes
> about this. All of these are options, maybe the component subscribes to the
> owners presence (but not subscribers) and can send them to all online
> owners, etc.. Maybe it round-robins them.. Maybe one of the configuration
> options is a "current approver" which is the JID of the person to get these
> (they must be an owner).
> > - The node discovery (examples 28 and 29) imply that the node
> > organization is   hierarchical with the '/' character being the level
> > separator. Is this   desired? Clearly it has benefits for discovery,
> > but it's not mentioned   elsewhere in the proposal.
> This is a possible way to implement it. I'll add some more notes. Currently,
> sect 5.1.1 specifies that node identifiers MAY have semantic meaning, but
> this needs have further clarification.
> > - Example 28 shows a 'name' attribute for nodes, but no other
> > discussion of   this node name appears. Should nodes have descriptive
> > names in addition to   their unique identifier?
> Again, descriptive names could be configured in the x-data form. The example
> shows a hierarchial system, and it's possible that the first level nodes are
> defined by the sys-admin. This type of stuff will be added to the impl.
> notes.
> > - Examples 3 and 4 contain the original <pubsub/> element in addition
> > to the   <error/> element in the response. No other error response
> > examples in this   document contain a copy of the original request.
> > Is it desireable to echo the   original request back to the sender in
> > this case? Why not for the other   example cases?
> Echoing the entire packet is not mandatory. Usually this is a by-product of
> the implementation just switching the to, from attributes and sending back
> an altered form of the original packet. I'm removing the <pubsub> elements
> from Example 3 & 4 to be more consistent, but I'll also add a note. I don't
> want clients to expect the <pubsub/> element to be there.. they should be
> tracking responses on the id attribute of the iq packet itself.
> > - There seems to be little useful distinction between the error code
> > 401 (Not   Authorized) and 405 (Not Allowed). This could use some
> > clarification.
> I'm adding a full error code table to the new draft.
> > - Examples 11 and 12 have an id= attribute on <message/> elements. I
> > understand   that while this is allowed by the Jabber protocol, it
> > does not have any   particular meaning and servers should not be
> > relied upon to maintain the id=   attribute when passing messages.
> Correct, I've removed the id attributes in messages for simplicity. However,
> any implementation may add ids when it desires to do so.
> > - Example 33 misspells configure as "confgure".
> Fixed :)
> > - Examples 34 and 38 use the type="get" for delete and purge
> > operations. Would   type="set" be more appropriate for these
> > destructive operations?
> Yes, agreed. New draft will use type="set" for these operations. Most of the
> examples were cut-n-paste, I probably didn't even think about sets :)
> > - Example 42 describes the error response as the node is not
> > *configured* for   persistent items, but the example message says the
> > feature is not   *implemented*. Which is it? (Section 3 allows that
> > persistent item storage is   an optional feature.)
> Some implementations may not allow ANY nodes to have persistent items. (IE,
> they have no back-end data store). For these systems 501 is the proper error
> msg. Implementations may put other CDATA into the error msg if they want to
> distinguish, but from an eitities perspective, it doesn't matter if the node
> wasn't configured for persistent storage, or the system doesn't. In both
> cases, "Purge" is an error case.
> > - Example 45 shows an owner setting the affiliation for a single
> > entity. The   DTD allows that more than one entity be specified here.
> > How should errors for   some, but not all, of the entity affiliation
> > assignments be handled?   According to table 2, some affiliation
> > state transitions are not permitted,   in particular revoking Owner
> > affiliation in any way other than demotion to   Publisher.
> I'm adding more examples and text for these cases.
> > There are some other features in JEP-0024 (I mentioned one above,
> > "Delivery Sensitivity") that would be useful. In particular, for
> > scalability, a way of batching and delivering published items to a
> > pubsub component on a remote server would be useful. For example, if
> > you had 500 items to publish to entities all at @jabber.org, it would
> > be useful to send the item once to pubsub.jabber.org and let it
> > handle subsequent delivery to clients.  JEP-0024 describes "Proxy
> > Subscriptions" in section 4.2.1. Some consideration should be given
> > to this scenario in the proposal.
> There are other possible reasons that I may NOT want batching also. For
> example, my component may be a load balancer to other pub-sub
> implementations, so I want to round-robin packets, I don't want to
> pull-apart batches before I do this.
> In the baseline specification, I think batching should not be included, as
> it can always be layered on top of this or just by using something other
> "wrapper" protocol.
> Thanx for the exhaustive comments.. I'll be pushing out a new draft once
> stpeter arrives back in town and can publish it.
> pgm.
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig

More information about the Standards mailing list