[standards-jig] LAST CALL: Service Discovery (JEP-0030)

Joe Hildebrand jhildebrand at jabber.com
Mon Mar 3 21:04:40 UTC 2003

Sorry it took so long for me on this.  I was out of town last week.

"Matthew A. Miller" <linuxwolf at outer-planes.no-ip.com> writes:

> If a *responding* disco entity wants to add semantic meaning, that's
> their prerogative, but *requesting* entities SHOULD NOT derive any
> such meaning.  IMO, if more meaning is necessary, then that's what
> another namespace should be for (sic x-commands).
> To demonstrate why I consider the above to be more correct, I point
> to (one of) the reason(s) for changing from revision 0.8 to revision
> 0.9 of JEP-0050[1]; this originally called for adding semantic
> value, but was seen as *undesirable* (possibly veto grounds?).  This
> was an application of disco that added semantic meaning, but the
> resulting discussion about it nullified adding such semantics.
> We need to be clear on this (overrated?) point of contention: If
> nodes *can* have semantic meaning, then the original text is fine,
> but then rev 0.8 of JEP-0050 is valid (and maybe even more
> desirable).  If nodes *cannot* have semantic meaning [outside of a
> specific implementation; e.g. a disco responder], then the original
> text really needs to be changed to something like that above.

How about this.  


The value of the node attribute may or may not have semantic meaning;
from the perspective of Service Discovery, a node is merely something
that is associated with a JID and for which the JID can provide
information. Any semantic meaning is provided by the protocol spoken
by the JID for a particular application.

with this:

The value of the node attribute MUST be treated as an opaque string.
A node is an identifier that is associated with a JID for which the
JID can also provide information.  The responding entity associated
with the JID may choose whatever semantic meaning it wants for node
names.  Examples might include a hierarchy, a hex representation of a
pointer to a structure, a GUID, etc.  Receivers MUST NOT make
inferences from the format of the node name.

Joe Hildebrand

More information about the Standards mailing list