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

Tue Nov 26 18:16:07 CST 2002

Some rather important things to note:

First, although namespaces in XML are supposed to be uniquely-qualified
URI's[1], the majority of (namespace-aware) XML applications and DOM
modelling libraries end up treating these as case-sensitive strings.

Second, the format given is not defined (to the best of my knowledge)
for the "jabber" URI scheme [2] (note that I said "URI" and not "URL"). 
This means that "jabber:iq:browse#info" may not technically be a valid
"sub-namespace" to "jabber:iq:browse".

Why are these important?  Because (in most cases) a Jabber entity
expecting "jabber:iq:browse" but getting "jabber:iq:browse#info" will
likey at best report a 501 (Not implemented) error, or at worst do
nothing.

It comes down to this: the suggestion  may not be backwards-compatible
with existing implementations.  This tends to lead to lots of unexpected
errors, and "bad blood" between the three "parties" to the development
efforts (user, client-implementor, component/server-implementor).

For this reason (and the reasons Rob has given slightly earlier) I think
it better to move forward with a new namespace rather than try and
extend an existing one.  But this is just my opinion.

- Matt

[1] W3C Recommendation 19990114 - "Namespaces in XML", Section 1:
Motivation and Summary (http://www.w3.org/TR/REC-xml-names/#sec-intro)
[2] RFC-2396 - "Uniform Resource Identifiers (URI): General Syntax",
Section 3: URI Syntactic Components
(http://zvon.org/tmRFC/RFC2396/Output/chapter3.html)

On Tue, 2002-11-26 at 15:23, 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 
> request! 
> 
> 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:
> CLIENT
> <iq to='component.jabber.org' type='get'>
> 	<item xmlns='jabber:iq:browse#info'/>
> </iq>
> 
> COMPONENT
> <iq from='component.jabber.org' type='result'>
> 	<item xmlns='jabber:iq:browse#info' type='jabber' name='something' 
> jid='component.jabber.org'>
> 		(<ns>jabber:iq:register</ns>) <- removed by restriction!
> 		(<ns>jabber:iq:gateway</ns>) <- removed by restriction!
> 		<info blah='xyz'>Someinfo</info>
> 	</item>
> </iq>
> 
> mfg Edrin
> 
> 
> On 26 Nov 2002 at 12:55, Ben Schumacher wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > 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.
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.0 (MingW32)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> > 
> > iD8DBQE949GoUpoGqensAXIRAlKwAJ9Mqonz/CrThsr7yB7m+AIsI4nriACgsAC1
> > U+MGEwAhsSStMM++ML6Gsnc=
> > =nep7
> > -----END PGP SIGNATURE-----
> > 
> > _______________________________________________
> > Members mailing list
> > Members at jabber.org
> > http://mailman.jabber.org/listinfo/members
> > 
> 
> 
> _______________________________________________
> Members mailing list
> Members at jabber.org
> http://mailman.jabber.org/listinfo/members
-- 

Matt "linuxwolf" Miller
JID:	linuxwolf at outer-planes.net
E-MAIL:	linuxwolf at outer-planes.net

- Got "JABBER"? (http://www.jabber.org/)