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

Nicholas Perez nick at jabberstudio.org
Wed Nov 27 01:42:06 CST 2002

What part of "INFORMATIONAL TRACK" do you not understand? Is it that big 
word that starts with an "eye"?

johannes.wagener at gmx.net wrote:

>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>
>	</item>
>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.)
>>Version: GnuPG v1.2.0 (MingW32)
>>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>Members mailing list
>>Members at jabber.org
>Members mailing list
>Members at jabber.org

More information about the Members mailing list