[standards-jig] JEP-0030, v. 0.9
theo at theoretic.com
Wed Jul 17 05:42:28 UTC 2002
I have some comments on the new JEP 0030.
First, some possible typos:
* The paragraph just after Example 8 has a typo which is easily found if
you read it aloud.
* Is the second "http" example in Example 31 supposed to be "https" instead?
Next, let me say I think Disco is definately going the right way for
discovery. There are a couple of oddball use cases that need to be taken
care of yet (pubsub, etc), but it the underlying "feel" and structure of
the protocol is for sure doing it the right way.
OK, I like that the JEP proposes a new role for the JSF, namely to act
as a naming and category authority for feature and entity categories and
types. However, I wonder if using names instead of namespaces in all
circumstances will not have its drawbacks. One issue crops up with
multiple versions. How does Disco current signify different versions of
protocols for features? What if there becomes an update to the XHTML or
conference protocols? Disco cannot curently say "this client supports
XHTML version 1.2" instead of having everyone assume XHTML 1.0 instead.
This is where the strict use of namespaces instead of simple names would
do good, since namespaces would already account for changes in version.
It is good that Disco allows for requestors to ask for a certain max of
results, but what about allowing requestors to specify what number of
results to start at as well? This would allow requestors to set a max
just in case the results may be in the hundreds or thousands, and
retrieve the left-out results if it does turn out to be so. "max of 50,
starting at result 1 (default)" followed by a "max of 50, starting at
result 51" if the first result proves to exceed that max.
I see that disco'ing for clients returns a list of clients/users
associated with that entity. Is this merely clients that are currently
logged in or online with that entity, or just registered or listed with
the entity? I think both situations should be accounted for in Disco,
since it would not only allow admins to query who is online to a server
*and* transports (replacing the clunky browse to "host.domain/admin"
JID), but allow them to see how many and who is registered with an
entity ("do I have a user named 'johnt'?") which is currently not
possible in the protocols.
What about also putting hardware resources up for discovery? This would
allow requestors to discover if servers or transports are heavily loaded
down in the bandwidth or processing department, and could notify the
requestor to wait or try and different server until it is better (or do
it automatically in some cases). This is something that is often talked
about for "intelligent p2p networks", and has a *lot* of potential. This
is something that should be seriously considered. Perhaps using a
<resources> or <hardwares> tag inside the <query> along with <entities>
The JEP needs to explain when and how the wildcard character of '*' can
be used in requests. It uses it in a couple of examples, but does not
give any rules for use. Also, what if the JID itself uses an astrix
(sp?) in the name? Unlikely, but you never know... unless the Jabber
Identifier spec forbids the use of an astrix, then that problem is
I will be working on some ideas of how to better integrate the pubsub
ideas into disco, but I don't think the suggested way of
"topic at component" is the best way. For one, I thought pubsub as it was
now had topics by publisher JID, not server-wide, "global" topic names.
That is, topic "xcv234" by publisher "user1 at host1" would be different
from topic "xcv234" by publisher "user2 at host2". I could be wrong,
though, I suppose...
Peter Saint-Andre wrote:
> I've added a bunch of examples to JEP-0030 (jabber:iq:disco) and made some
> other modifications here and there. Let me know what you think.
/\ Adam Theo, Age 23, Tallahassee FL USA
//\\ Email & Jabber: theo at theoretic.com
// \\ (Boycotting AOL, therefore no AIM or ICQ)
// || \\ Theoretic Solutions: http://www.theoretic.com
|| "Building Ideas by Bringing them Together"
|| Jabber Protocol: http://www.jabber.org
|| "The Next Generation Communications Protocol"
|| "A Free-Market Socialist Patriotic American Buddhist"
More information about the Standards