[standards-jig] Re: My take on service discovery

Jean-Louis Seguineau/EXC/TEC jean-louis.seguineau at antepo.com
Mon Dec 2 17:54:27 UTC 2002


Being of a precise and efficient mind, I would say that the current issue of
the JEP lack a well organized decription of what MAY, SHOULD and MUST be
done with the protocol. It is a simple as that. I cannot have someone work
at implemeting that JEP as there is too much left to the implemetor. Does
that make sense ?

What I call a ready for prime time JEP is something that consider all points
of view, without prejudice being on the client side and on the server side,
and states clearly what would be compliant and what would not. In short be a
reference, not a simple guideline.

I am not talking about justifying, as this will no doubt end in an hoted up
discussion, just specifying (isn't that the goal of a JEP ?) There is two
way to go about this:
1/ either the JEP clearly states what complies, and explain how to react
when something is not compliant (that includes standard use cases and
behaviour, but also and above all error state that must be conveyed back to
the requester when dealing with the unexpected)
2/ or it clearly state that it is only a framework and that any such
decision should be left to the implementation.

Both cases suit me fine, as long as one is agreed upon and documented. This
is not the case right now. These are my requirements, and as you can see it
does not boils down to technicalities, but simply mere usability. Even the
core protocol is far from being perfect on that subject, otherwise there
wouldn't be a need for books to be written on the subject, isn't it :) This
is why we end up having as many interpretation as there are implementations.
This is an important part of the protocol, as it should allow to find about
offered features. Without clearly stating what is allowed and what is not,
what rule to use to extend it, I am affraid we would have another
jabber:iq:browse in disguise. Everybody knows about it, but nobody aggrees
on how to use it.

Prime time means precision of usage. Full stop.


P.S. your motion having received six seconds, this JEP will go to last call.
But isn't it a feable justification for it....

----- Original Message -----
> Message: 6
> Date: Thu, 28 Nov 2002 09:46:34 +1100
> From: Robert Norris <rob at cataclysm.cx>
> To: standards-jig at jabber.org
> Cc: members at jabber.org
> Subject: [standards-jig] Re: [Foundation] My take on service discovery
> Reply-To: standards-jig at jabber.org
> --wzJLGUyc3ArbnUjN
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> > Although I perfectly see the interest of having a dynamic protocol to
> ow
> > a server to discover at run time what services there is, and make it
> > available to its client, I am affraid the disco protocol as it stands is
> far
> > for being ready for prime time.
> Could you please give some clear reasons as to why you think it is not
> for prime time. Clearly, you have a different set of requirements in
mind -
> communicating those may reveal something that has not been addressed.
> > In the end do we want a protocol extension that would allow anybody to
> ild
> > something on top of it, or do we want just a jabber2 compliant protocol
> I wasn't talking about disco being jabberd2 specific - it certainly is
> not. In fact, the conception of disco goes back to long before jabberd2
> was begun.
> What I was talking about was a simple internal protocol to move data
> between the router and SM components of jabberd2.
> Additionally, I note that (as I write this), my motion has received six
> seconds, so this JEP will go to last call. Further discussion should
> really go to standards-jig (which is why I'm posting it there and CCing
> it to members@).
> I also note that noone has been able to articulate a clear reason why
> disco does not meet its stated requirements. The only real argument that
> I've seen so far is from a couple of client authors who would prefer
> that browse be incrementally updated to move towards providing the same
> set of features as disco does.
> (While I don't beleive that such a transition is possible, one of the
> aforementioned articles claims that it is possible. There was a long
> discussion[1] about this in jdev at c.j.o yesterday. One of the
> aforementioned client authors has offered to document such a
> transition).
> Rob.

More information about the Standards mailing list