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

Peter Saint-Andre stpeter at jabber.org
Thu May 8 16:35:12 CDT 2003

On Wed, Apr 09, 2003 at 01:07:44PM -0600, David Waite wrote:

> - 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'm finally working on a new XML format for this registry and am now
removing categories/types that are not currently implemented or for which
we do not have Draft/Final protocol. IMHO we cannot quite restrict the
registry to standards defined in JEPs, because we do have entities out
there on the network (e.g., gateways) that are not defined by a JEP but
that are well-known. However, I have drastically reduced the seeding
here to the following categories and types:




Peter Saint-Andre
Jabber Software Foundation

More information about the Council mailing list