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

Adam Theo theo at theoretic.com
Mon Jul 22 05:31:13 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 
reached.

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 some
> 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"




More information about the Standards mailing list