[Foundation] Motion to propose JEP-0030 (Service Discovery) to council

johannes.wagener at gmx.net johannes.wagener at gmx.net
Tue Nov 26 17:23:59 CST 2002

You can extend jabber:iq:browse quite easily! If you do that it will get all the features 
required/mentioned in JEP-0030 and will also still continue to be compatible with all 
current implementations!
Also by doing this the jabber:iq:browse would not go to look hackish! (we do not have to 
fear that!)

This would mean much less work for us client coders... and older components will still 
work and if a JID does not support restrictions yet the user can do a normal browse 

It is much easier to extend my own ocde then to write a new one!

My SUGGESTION just add this to the JEP-0011:
add the restirction options to the jabber:iq:browse with #option
add some other level stuff like <ns/>
for example:
<iq to='component.jabber.org' type='get'>
	<item xmlns='jabber:iq:browse#info'/>

<iq from='component.jabber.org' type='result'>
	<item xmlns='jabber:iq:browse#info' type='jabber' name='something' 
		(<ns>jabber:iq:register</ns>) <- removed by restriction!
		(<ns>jabber:iq:gateway</ns>) <- removed by restriction!
		<info blah='xyz'>Someinfo</info>

mfg Edrin

On 26 Nov 2002 at 12:55, Ben Schumacher wrote:

> Hash: SHA1
> Richard Dobson wrote:
> | I think the disco namespace in its current form, is much better than
> it used
> | to be (havent looked at it in ages) and it is now not really very far away
> | from what browse is anyway so am not sure what the fuss is about, I think
> | what this boils down to is that people are going to have to support two
> | different methods of browsing in their clients/servers/components but dont
> | want to have to.
> Why would you support two different methods? I see no reason to continue
> to support browse, in fact, any new component I write will not. There is
> no reason to support two different methods, because there is only one
> method that has been decided by the council to be part of the protocol
> moving forward. The informational iq:browse JEP simply documents
> something that was used at one point in time, but which has obvious
> issues. Trying to "fix" the issues in iq:browse is exactly the point of
> the standards track service discovery JEP. Reusing the same namespace
> only complicates the issue, and doesn't add any value. If I were a
> client author, after the JEP was accepted, I would remove iq:browse
> support and plug in iq:disco support. While it might take a while for
> some components to catch up, it would ultimately serve the community better.
> iq:browse will probably be deprecated when disco is advanced by the
> council. Components and clients MAY continue to support it, but it is
> not required. Ultimately, it is up to the council to decide what's best
> for the protocol, and it is up to the community to vote on council
> members who we think will best represent our views. That's the way the
> system works. If you have a technical problem with service discovery,
> please feel free to share with the rest of us, and the council members
> will surely take that into account when the JEP goes to a vote. If,
> however, your only objection is simply the fact that you don't want to
> do the work to implement the protocol then I suggest you suck it up and
> deal with it. While this might save you x number of hours of work, it
> ultimately damages the protocol and will probably mean more work down
> the line for developers as they continually have to work around the
> mistakes of the past. (Think Y2K.)
> Cheers,
> bs.
> Version: GnuPG v1.2.0 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> iD8DBQE949GoUpoGqensAXIRAlKwAJ9Mqonz/CrThsr7yB7m+AIsI4nriACgsAC1
> U+MGEwAhsSStMM++ML6Gsnc=
> =nep7
> _______________________________________________
> Members mailing list
> Members at jabber.org
> http://mailman.jabber.org/listinfo/members

More information about the Members mailing list