[standards-jig] JEP-0030, v. 0.9

Adam Theo 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> 
and <features>?

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 
solved/answered  :-)

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.
> 
> http://www.jabber.org/jeps/jep-0030.html

-- 
     /\  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 mailing list