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

Robert Norris rob at cataclysm.cx
Thu Jul 18 09:02:21 UTC 2002

> I have some comments on the new JEP 0030.

So do I :)

> 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?

Some minor nitpicks of my own:

 * Example 6; the first attribute of the returned entities should be
              "category", not "type".
 * Example 20, 21, 22; is querying for "resources" the correct
 * Example 22; the description says we're querying a conference service,
               but the example shows a query to a news service.
 * Example 23; the first returned entity has a double apostrophe at the

> 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.

I agree completely. This is definently a step in the right direction,
and I'm thorougly looking forward to seeing some implementations.

> 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.

It may also be of use for the total number of entities to be returned,
so the client knows how many haven't been requested. Maybe we could
optionally number the returned entities.

> 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.

It might be easier to define a category and types for this. Perhaps
something like users:online, users:offline, users:all. Though, this
would mean that users move between type "online" and type "offline",
which might not make sense.

Of course, this makes it harder to determine the client type, since
we've already used the category and the type, which leads me into a
something thats been bothering me all day (since I read this last
night): the pair of category and type are essentially creating the top
two levels of a hierarchy, even though they are somewhat arbitrary and
usually application-specific.

I wonder if it would be more flexible to have a single type field which,
for certain applications, can have a hierarchy within it if necessary,

  <iq type='get' from='requestor' to='jabber.org' id='gateway1'>
    <query xmlns='jabber:iq:disco'>
      <entities type='gateway'/>

  <iq type='result' to='requestor' from='jabber.org' id='gateway1'>
    <query xmlns='jabber:iq:disco'>
        <entity type='gateway/icq' jid='icq.jabber.org'/>
        <entity type='gateway/msn' jid='msn.jabber.org'/>
        <entity type='gateway/sms' jid='sms.jabber.org'/>

Of course, it can still be limited further by requesting something
further down in the hierarchy, eg <entities type='gateway/icq'/>.

Another way in which more information could be specified is via an
application-specific XML fragment inside the entity tag. This way, we
could do something like:

  <iq type='get' from='requestor' to='jabber.org' id='users1'>
    <query xmlns='jabber:iq:disco'>
      <entities type='users'/>

  <iq type='result' to='requestor' from='jabber.org' id='users1'>
    <query xmlns='jabber:iq:disco'>
        <entity type='users/online' jid='jer at jabber.org/cell'><x xmlns='disco:client'>portable</x></entity>
        <entity type='users/online' jid='jer at jabber.org/gabber'><x xmlns='disco:client'>full</x></entity>
        <entity type='users/offline' jid='stpeter at jabber.org'/>

I also question whether, in example 23, the query should have been sent
to the user and not the host. I can see pros and cons for both aspects

In the case where application-specific functionallity needs to be more
widely used, then the types and/or namespaces can be submitted to the
JSF as a new JEP, which depends on this one. This would also mean that
the JSF no longer needs to perform a seperate registry function - it can
simply continue to approve JEPs, and the JEPs that define disco types
and namespaces are the offical ones.

> 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>?

Again, this a specific application, which should be defined outside of
the core disco spec.

> 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  :-)

Yes, I noticed this one too. According to JEP-0029, an asterix is
allowed in the node or resource parts of a JID, which of course means we
can't use it as a wildcard.

Again, since wildcards are not applicable for every application, why not
leave it out of the core disco spec, and have an extensions for
applications that require it. This will allow the search method to be
tailored to the service type. For newsgroups, a simple asterix may be
enough to match them, so the query might look something like this:

  <iq type='get' from='requestor' to='newsgroups.jabber.org' id='newsgroup1'>
    <query xmlns='jabber:iq:disco'>
      <entities type='newsgroups'><x xmlns='disco:newsgroups'>comp.ai.*</x></entities>

Some other type of service may require something more complex, like a
regular expression or something. This way, disco services that are quite
simple and don't need any kind of wildcard matching aren't required to
implement it.


Robert Norris                                       GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20020718/3807c2ae/attachment.sig>

More information about the Standards mailing list