[standards-jig] JEP-0030, v. 0.9

Adam Theo theo at theoretic.com
Wed Jul 31 19:28:36 UTC 2002

Rob Norris and I have spent a good chunk of the past few hours heavily
discussing JEP 0030, Disco. Here is a summary of the issues we have come
to agreement on that change the current JEP.

First, some typo and other editorial comments (many of which are from
previous posts re-highlighted here):
* Example 6; the first attribute of the returned entities should be
"category", not "type".
* Example 8: The paragraph just after has a typo which is easily found
if you read it aloud.
* Example 20, 21, 22; is querying for "resources" the correct description?
* Example 22; the description says we're querying a conference service,
but the example shows a query to a news service.
* Example 23; the first returned entity has a double apostrophe at the end.
* Example 31: Is the second "http" example supposed to be "https" instead?
* And a general comment that the JID examples throughout the JEP are not
very consistent. I think someone should go through it again, paying
attention to just the JID examples, and re-do them to make it seem like
it was all written by the same author.
* Another general comment about the examples in the JEP is that they too
are not consistent in all ways. Example 32 has comments about the
process of the packets inline, whereas no other examples do. The same
should be done as to the JID examples.

Second, the CDATA option really should be taken out of <feature> and
<entity> elements. As Rob pointed out to me, the CDATA would be in the
disco namespace, so would have to be defined in the JEP to be of any
real use. It would be better to restrict all child content as XML with
their own namespaces.

Third, Shouldn't the <identity> tag also allow for XML, to ensure the
extensibility and future-proof claim that the JEP makes over Browse?

Fourth, Shouldn't the "jid" attribute be taken out of the <identity>
element? The jid is already known, obviously, so why repeat it? the
"jid" attribute is not found in the <feature> element, so why require it
in <identity>?

Fifth, I agree with Rob that the "type" and "category" attributes in all
elements should be merged into a single "type" attribute. Entities and
features would be "typed" as arbitrary strings that are registered with
the JSF, formalized in JEPs, or used in third-party applications alone.
Hierarchy would still exist, but it would not be hard-coded into the
spec, and therefore would not be forced to no less than or greater than
2 levels in said hierarchy. It is best left free-form from the
protocol's viewpoint in order to ensure future-proofing. For example,
instead of "Connection" and "ssl", you would simply have "connection/ssl".

Sixth, I would like to see the option for hardware resources such as
bandwidth pipes, CPU, display resolution, and such being discoverable in
Disco. If they were, then users would be able to see the display
resolution of the device, the operating system and/or programming
language of the entity, and if the device had a high-speed Internet
access or not. <resource> would allow XML children, so could hand out
statistics or stats about the hardware resource such as CPU load,
bandwidth activity, desktop idle time, etc. Note that this would follow
Disco's policy of leaving permissions and access control completely
outside the scope of the spec. Therefore these informations are likely
to be controlled and restricted, it's just that the Disco spec will not
go into length explaining how, that's up to a future JEP. I would like
to see these hardware resource informations have their own element along
with <identity>, <feature>, and <entity>, called <resources>, but I
would be satisfied with just having them lumped into <features> with a
mention and examples of the possabilities. Who feels one way or the
other about this?

Seventh, two attributes should be added to <entities>, <features>, and
<resources> (if added) in addition to the current "max" attribute. With
max, a requestor can ask for a maximum number of results, but there is
no way to pick up from the end of that if the results do prove to be too
long. There should also be a "start" attribute to go along with "max" to
signify where to begin counting from. This will allow requestors to
retrieve results in chunks. Also, when results are sent back to the
requestor, an attribute of "total" should be included with <entities>,
<features>, and <resources> (if added). "total" should indicate the
total number of results there are, including the number returned.
Whether "total" is only returned if "max" is asked for and the limit is
reached, or returned at all times, is up for debate. I personally would
say it is returned only if "max" is asked for, even if the limit is not

Eighth, I feel a W3C XML Schema of the Disco protocol should be included
in the JEP. It would add some length to the spec, but I personally would
rather have it than not. Disco will be a very important spec, and making
sure the format and options are clear to everyone is a must.

Peter Saint-Andre wrote:
 > I've added a bunch of examples to JEP-0030 (jabber:iq:disco) and made 
 > other modifications here and there. Let me know what you think.
 > http://www.jabber.org/jeps/jep-0030.html
 > Thanks!

      /\  Adam Theo, Age 23, Tallahassee FL USA
     //\\   Email & Jabber: theo at theoretic.com
    //  \\  (Boycotting AOL, therefore no AIM or ICQ)
//  ||  \\  Theoretic Solutions: http://www.theoretic.com
      ||         "Building Ideas by Bringing them Together"
      ||      Jabber Protocol: http://www.jabber.org
      ||         "The Next Generation Communications Protocol"
      ||  "A Free-Market Socialist Patriotic American Buddhist"

Standards-JIG mailing list
Standards-JIG at jabber.org

More information about the Standards mailing list