[standards-jig] JEP-50 Sponsorship
Matthew A. Miller
linuxwolf at outer-planes.no-ip.com
Tue Apr 22 16:34:52 UTC 2003
On Tue, 2003-04-22 at 08:51, Joe Hildebrand wrote:
> - First sentance of 2.1 doesn't parse. I think there is supposed to be a
> period in there.
This will be fixed immediately (durn you, ukscone, you were supposed to
catch that!! (-: ).
> - In 2.2, perhaps a note that says that the disco#items results could have
> different jids than the jid you sent the query to. (redirects)
Personally, I would consider any retrieval of a command-list, containing
commands NOT from this JID, to be a serious security concern, likely a
violation. Is there a truly valid use-case for having a redirect,
within the context of command lists?
Until someone can strongly convince me otherwise, that's as far as I'm
willing to go on this.
> - In 2.3, the presence thing makes me nervous. I'm not sure how receivers
> are supposed to deal with this. Assuming the receiver is a client, is it
> supposed to render this each time it is received? Cache it for later? (the
> latter actually could make sense, I suppose...) Presumably for <message/>
> the client is always supposed to render the command list at that point in
The intention was, when an entity announced its availability, any
subscribers could also "automatically" respond in-kind with their
command-driven capabilities (makes generating that context menu a little
easier). This is more easily handled, and less forced-upon, by using
<message/>, so I can remove the <presence/> references.
> - In 2.4.1, is there precedence between the x:data result and oob's? or
> should I always handle all of them?
My thoughts were that precedence would be handled by element order.
While XML does not exactly guarantee ordering in the current draft, the
de facto standard is that order is maintained. If this is acceptable,
I'll add a note about this to the appropriate "Formal Description"
Personally, I would rather have x:data take precedence, if the above is
not realistic. Of course, this preference can change over time, which
is why I would really hope that order is acceptable.
> - In 2.4, perhaps it should be <iq type='get'> for simple execution, which
> MAY return a form, and then <iq type='set'> to submit the form. I think
> server-side implementation will be a little easier, then.
This would mean that the requester knows something about the command,
which it may or may not (likely not). Also, this only works if there's
a SINGLE form in the whole mix, which may or may not be true. I know I
can think of a few dozen applications where multiple forms are better
than one long form, and I'm sure others can, too.
> - Should example 14 just be x:data results? I don't feel strongly about
> this one.
The example can go either way. For this particular example, it could
have been used, but then it is just an informational note, which <note
type='info'/> is exactly intended for.
> - In 2.4.3, can we use the existing x:data cancel semantics, if there is a
> form in progress? That might lead to the removal of the action attribute.
Provided that x:data is ALWAYS used, then that can be a possibility.
This protocol has actually removed much of its dependence on x:data,
mostly from on- and offline discussions.
Additionally, I was hoping to one day make use of this attribute for a
follow-on to xcommands; to provide limited, wizard-/druid-like flow
> - 4.2: schema will be required before it goes draft.
This is actually already present in the XML "source". Somehow an update
got missed, around the same time as the disco "node" controversy, and
the bytestreams vs. DTCP debacle...so who can blame psa? (-:
> - In 7, will it be possible for the Jabber Registrar to register particular
> command names, like JEP-68? Again, not something I feel strongly about, but
> a sentance here may save us a JEP later.
Personally, I see no point to this. Command names are not intended to
be absolute; they have a context, which is the responder. Also, from
discussions both here and in the groupchat's, there's a lot of
subjective opinions on what even the simple names "list" and "config"
would really mean.
> All in all, this JEP is fabulous. Great work linuxwolf.
> > -----Original Message-----
> > From: Thomas Muldowney [mailto:temas at box5.net]
> > Sent: Monday, April 21, 2003 10:23 PM
> > To: standards-jig at jabberstudio.org
> > Subject: [standards-jig] JEP-50 Sponsorship
> > I'm sponsoring JEP-50 and I'm motioning for Last Call on it.
> > It's time
> > to speak up if you have any thoughts or concerns.
> > --temas
> Standards-JIG mailing list
> Standards-JIG at jabber.org
Matt "linuxwolf" Miller
JID: linuxwolf at outer-planes.net
E-MAIL: linuxwolf at outer-planes.net
- Got "JABBER"? (http://www.jabber.org/)
More information about the Standards