[standards-jig] Some thoughts on JEP0030 Service Discovery

Peter Saint-Andre stpeter at jabber.org
Fri May 31 03:16:54 UTC 2002

Hi DJ,

You make some good points. I added a few little words here and there to
address your first two points. The others are bigger issues and we'll need
to think about them. Or at least I will -- I'm not as quick as the rest of
the protocol gurus around here.

Slightly updated version here (minimally organized around use cases):



Peter Saint-Andre
Jabber Software Foundation

On Mon, 20 May 2002, DJ Adams wrote:

> Hi all
> well, I finally got round to reading 0030 Service Discovery. I had a 
> few thoughts, some of which I've already discussed in part with Ryan,
> but I thought it was worth noting them down here:
> Inflexibility?
> --------------
> 1.1. "The protocol is not easily extensible...categories and subcategories
> ...explicitly defined as the only valid categories"
> I'd take issue with this; as far as I understand it, an explicit provision
> in the form of the 'x-' prefix was made in iq:browse for subcategories. So
> iq:browse isn't as inflexible as this section of 0030 might suggest.
> Discovery vs Navigation
> -----------------------
> 1. "To address these shortcomings...new protocol that is intended to 
> supersede jabber:iq:browse".
> Now this is really just wording and / or semantics, but I think it's
> important to stress (or not lose sight of the fact that) iq:browse isn't
> just service discovery. It's a generic way of navigating hierarchies of
> entities (things with JID addresses). While 'browse' suggests navigation,
> 'disco' suggests discovery. So neither is totally accurate, or can be. 
> Perhaps it's just worth putting in a note that iq:disco intends to 
> support all the uses of iq:browse (discovery, navigation, etc).
> IRC Channel List example
> ------------------------
> The 'what IRC channels are there' example use of browse was rightly 
> cited as an instance where too much data comes back down the pipe as
> a result. But it's not obvious where the problem lies, and how iq:disco
> might address it.
> Too much for the computer? - how about support for an iq:search style
> multi-packet result (iq-set...iq-set...iq-result)?
> Too much for the human? - well, assuming the implicit answer is to use
> filters (e.g. <feature type='connection'/> in Example 7), how might that
> work in this IRC channel context, or any context where we don't _control_
> the metadata? I understand there was some discussion of using a max='n'
> attribute in the request, but this would only make sense if it was 
> accompanied by a startingfrom='' type mechanism too. And that usually
> implies some sort of state. 
> Melding with Pubsub
> -------------------
> In section 4, a brief mention of pubsub is to be found. Is it possible
> to have an example of how this might work? Considering the status of
> the current proposals, this might sound like a leading question ;-) But
> it's not. I just think it would be useful to have an example. 
> Well, that's just my 2p as usual
> dj
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig

More information about the Standards mailing list