[Standards-JIG] NEW: JEP-0128 (Service Discovery Extensions)
jabber.org at ralphm.ik.nu
Sun Mar 7 12:52:00 UTC 2004
On Sat, Mar 06, 2004 at 06:55:11PM +0100, Jacek Konieczny wrote:
> On Fri, Mar 05, 2004 at 04:52:34PM -0600, Peter Saint-Andre wrote:
> > As discussed recently on this list, sometimes it would be helpful to
> > extend service discovery IQ results. This JEP describes a recommended
> > approach for doing so by means of jabber:x:data.
> > http://www.jabber.org/jeps/jep-0128.html
> Why did you change jabber:x:data protocol and semantics??
> Data form of type "result" was supposed to contain a set of results
> of a data query including field names (table heading) and a list of
> records (table data rows) containing fixed field number. This protocol
> was accepted as Final it cannot be just changed, because someone would
> like it better this way.
As I read JEP-0004, section 4.2, the use of form type 'result' has the
Data results being returned from a search, or some other query.
The JEP goes on to explain a few possible uses of jabber:x:data, among
which the use of type='result' for returning the results of a search
using jabber:iq:search. This is aided by some special field for dividing the
results in <item/>s and by giving hints to the user-agent using <reported/>.
Never does it say in the JEP that this is the only possibly use of
type='result', and in fact the last part of the description above says '... or
some other query'. So, as I understand it, you can just return a form without
<item/> and <reported/> for a simple query like this, using type='result'.
> Now you made a JEP using the same namespace i quite different protocol.
> This is really evil. If the protocol is going to be defined this way
> no one will trust JSF extensions as good protocol specification.
Sorry, but I don't agree at all. Also, I don't believe one /proposal/ has
such impact to not trust the JSF extensions any more.
> If jabber:x:data is to be used it must be used as it is defined in
> JEP-4. If that jabber:x:data definition is not good, then a new
> protocol, with new namespace should be proposed.
Again, I think this proposal is compliant with JEP-0004.
More information about the Standards