[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 
> flexibility 
> > 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 mailing list