[Standards-JIG] JEP-0060: Comments on latest draft.
Fletcher, Boyd C. J9C534
Boyd.Fletcher at je.jfcom.mil
Sat Jun 26 00:02:34 UTC 2004
> -----Original Message-----
> From: Bob Wyman [mailto:bob at wyman.us]
> Sent: Friday, June 25, 2004 7:28 PM
> To: Fletcher, Boyd C. J9C534; 'Jabber protocol discussion list'
> Subject: RE: [Standards-JIG] JEP-0060: Comments on latest draft.
> Boyd Fletcher wrote:
> > There are child nodes in JEP-060 because JEP-60 uses Disco which
> > allows them so might notification problem still exists.
> Disco allows you to discover nodes which are items of a
> node. The fact that a node is an item of another node does
> not imply any "parent/child" relationship. It only means what
> it says: One node is an item of another.
a node that is an item of another node is for all pratical purposes a "child" of that node.
> The fact that one node is an item of another node is
> completely irrelevant in JEP-0060 for any purpose other than
> browsing UNLESS the containing node is a Container. In that
> case, section 10.1 is relevant.
humm. yet another ambiguity. Thank was not our interpretation.
> Disco is *not* relevant to notification...
I wasn't trying to imply that it did. the specification does not (at least to us) adequately explain how notification works for sub-nodes or items of sub-nodes.
> I wrote:
> > It is clear that you would like to remove much of the
> > from the current JEP-0060 spec. However, I think
> You wrote:
> > I've NEVER said anything about removing functionality.
> Well, I didn't either. You seem to have misread my
> message every time the word "flexibility" appeared.
> Apparently, wherever I wrote "flexibility" you read
> "functionality." The two are very different concepts.
ok. fair enough. but flexbility is *not* the same thing as making a specification non-ambiguous. The whole node/item update portion is completely ambiguous. The way 11.3 is written it is impossible for client to reliably know how the server will react to a update request or to discover the server's update node/item capabilities.
> > Making a specification clear and concise does *not* mean you remove
> > functionlity.
> But, the way that you wish to modify JEP-0060, it
> *would* remove flexibility. The use of the word "MUST"
> virtually always implies a reduction of flexibility.
What we have now with JEP-060 is a specification in which interoperability is impossible. I am far more concerned about interoperable pubsub implementation that a slight perceived loss of flexibility. One way to make a flexibility specification is to provide a method for clients and servers to discover all of the optional parts of the protocol - this is currently not the case in PubSub. However, that being said I see nothing wrong with making a certain subset of the specification mandatory. Update nodes/items is one of the those things that is critical to most (if not all) pubsub implementations. So we could rewrite what I wrote to say then at minimum it must support overwrite, read-only, and append but we could provide a mechanism to extend that functionality for other methods.
> > What you are advocating is that everyone should write their
> own pubsub
> > service, ... A pubsub service should be generic enough that
> it can be
> > used for a wide variety of purposes.
> This isn't even vaguely related to reality. I have
> never, and will never, suggest such a thing. In fact, I've
> been working hard to ensure that the capabilities we need are
> reflected in JEP-0060 precisely so that what we do will *NOT*
> be a unique, proprietary implementation.
Then surely you should see the necessity of:
1) removing all the ambiguities from the specification
2) clearly defining how a client can discover any optional (should or may) parts of the specification
3) establish a method to extend the protocol for custom uses without invalidating the core spec.
> I repeat: Instead of your trying to remove what you
> call "ambiguity"
> by removing flexibility from the specification, it would be
> much more useful if you focused on proposing concrete methods
> by which applications can discover at run-time the various
> choices made by implementers of the servers or those who
> configured the nodes. (i.e. propose mechanisms for expressing
> and discovering the choices.)
some parts of the specification are ambiguous and need to be fixed like node/item updates.
I think you are getting "fixing ambiguities" confused with making sure all the optional parts of the specification are discoverable. They are not the same thing.
> bob wyman
More information about the Standards