[Council] VOTE: Service Discovery (JEP-0030)

Julian Missig julian at jabber.org
Wed Apr 9 15:15:40 CDT 2003

On Wednesday, Apr 9, 2003, at 15:07 US/Eastern, David Waite wrote:

> Peter Saint-Andre wrote:
>> It's time to vote on Service Discovery (JEP-0030). This is a 
>> standards track JEP, so your +1 vote means you approve of advancing 
>> this JEP to Draft. If you vote -1, please provide a reason.
>> http://www.jabber.org/jeps/jep-0030.html
>> Peter
> +1, but not without comments :-)
> - It seems that the ability to delegate feature support to another JID 
> would be nice; for example, I might want searches against my muc 
> implementation to go against a database, which provides history 
> searching as well.  An alternate implementation could redirect on 
> search requests, but of course redirection of this sort is not 
> standardized. I figure if this i needed, it will come up during 
> implementation. It could be made as an extension of service discovery 
> as well.
> - I know I've brought this up before, but I still think it would be 
> nice if you could a query of both features and (child) items in one 
> fell swoop with a single iq. It adds no functionality, but it prevents 
> one round-trip and a couple hundred bytes of traffic every time you 
> connect to your server.
> - I'm still frustrated that the JANA category types and feature 
> seeding is still in there. Knowing that a node provides 'game/chess' 
> does not help the fact that we have no corresponding 'game/chess' 
> protocol to work with. The "presence-invisible" feature is a 
> standards-track proposal for addition of an informational JEP feature 
> (which isn't even defined in that informational JEP) - there is 
> absolutely no definition of how to discover this feature or what its 
> 'presence' implies (although it is feasable to guess). These 
> categories types and features should be standardized by appropriate 
> JEPs or at least developer requests; then the meaning of them can be 
> properly defined.
> I'm not going to hold up this JEP up because of the seeding (partially 
> because I've held it up enough - stpeter I _swear_ I sent this email 
> before), but the whole point of JANA is to have these definitions 
> centralized so that we can properly track the list in this JEP. 
> Tracking the definition of  a 'directory/room' to a single line in the 
> service-disovery JEP rather than MUC or some other JEP that describes 
> the expected features corresponding to a 'directory/room' limits the 
> usefulness of that centralized JANA list.

I just wanted to say that I agree with your comments. So, uh, "me too"


More information about the Council mailing list