[standards-jig] JEP-50 Sponsorship

Joe Hildebrand jhildebrand at jabber.com
Tue Apr 22 17:10:04 UTC 2003

(sorry for the supercite foo, but I was getting confused...)

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

    hildjj> - In 2.2, perhaps a note that says that the
    hildjj> disco#items results could have different jids
    hildjj> than the jid you sent the query to.  (redirects)

    lw> Personally, I would consider any retrieval of a
    lw> command-list, containing commands NOT from this JID,
    lw> to be a serious security concern, likely a
    lw> violation.  Is there a truly valid use-case for
    lw> having a redirect, within the context of command
    lw> lists?

    lw> Until someone can strongly convince me otherwise,
    lw> that's as far as I'm willing to go on this.

I'd be ok with a MUST NOT here, too, since I see your point.

    hildjj> - In 2.3, the presence thing makes me nervous.
    hildjj> I'm not sure how receivers are supposed to deal
    hildjj> with this.  Assuming the receiver is a client,
    hildjj> is it supposed to render this each time it is
    hildjj> received?  Cache it for later?  (the latter
    hildjj> actually could make sense, I suppose...)
    hildjj> Presumably for <message/> the client is always
    hildjj> supposed to render the command list at that
    hildjj> point in time.

    lw> The intention was, when an entity announced its
    lw> availability, any subscribers could also
    lw> "automatically" respond in-kind with their
    lw> command-driven capabilities (makes generating that
    lw> context menu a little easier).  This is more easily
    lw> handled, and less forced-upon, by using <message/>,
    lw> so I can remove the <presence/> references.

And pub/sub can be used also, but I don't think we should
hold this JEP up for 60 by mentioning it here.

    hildjj> - In 2.4.1, is there precedence between the
    hildjj> x:data result and oob's? or should I always
    hildjj> handle all of them?

    lw> My thoughts were that precedence would be handled by
    lw> element order.  While XML does not exactly guarantee
    lw> ordering in the current draft, the de facto standard
    lw> is that order is maintained.  If this is acceptable,
    lw> I'll add a note about this to the appropriate
    lw> "Formal Description" sub-section.

    lw> Personally, I would rather have x:data take
    lw> precedence, if the above is not realistic.  Of
    lw> course, this preference can change over time, which
    lw> is why I would really hope that order is acceptable.

I'm ok with using XML order, but it needs to be explicit
that these are alternatives, not multiple parts of the same

    hildjj> - In 2.4, perhaps it should be <iq type='get'>
    hildjj> for simple execution, which MAY return a form,
    hildjj> and then <iq type='set'> to submit the form.  I
    hildjj> think server-side implementation will be a
    hildjj> little easier, then.

    lw> This would mean that the requester knows something
    lw> about the command, which it may or may not (likely
    lw> not).  Also, this only works if there's a SINGLE
    lw> form in the whole mix, which may or may not be true.
    lw> I know I can think of a few dozen applications where
    lw> multiple forms are better than one long form, and
    lw> I'm sure others can, too.

Hm.  The multiple form thing bit wasn't clear to me from the
JEP.  Maybe there needs to be a couple more examples.  I
still think that each new stage could start with a get,
which MAY return a form.  And, there may be intermediate
results, as well:

1 simple command:
C: iq/get
S: iq/result, command/status=completed, x:data results (maybe)

1 form:
C: iq/get
S: iq/result, command/status=executing, x:data form
C: iq/set, x:data submit
S: iq/result, command/status=completed, x:data results (maybe)

n forms:
C: iq/get
S: iq/result, command/status=executing, x:data form
C: iq/set, x:data submit
S: iq/result, command/status=executing, x:data results (maybe)
... repeat
C: iq/get
S: iq/result, command/status=executing, x:data form
C: iq/set, x:data submit
S: iq/result, command/status=completed, x:data results (maybe)

    hildjj> - In 2.4.3, can we use the existing x:data
    hildjj> cancel semantics, if there is a form in
    hildjj> progress?  That might lead to the removal of the
    hildjj> action attribute.

    lw> Provided that x:data is ALWAYS used, then that can
    lw> be a possibility.  This protocol has actually
    lw> removed much of its dependence on x:data, mostly
    lw> from on- and offline discussions.

    lw> Additionally, I was hoping to one day make use of
    lw> this attribute for a follow-on to xcommands; to
    lw> provide limited, wizard-/druid-like flow control.

After working through the multi-form thing above, I agree
with you.  However, an x:data cancel at any point should
*also* cancel the session.

    hildjj> - In 7, will it be possible for the Jabber
    hildjj> Registrar to register particular command names,
    hildjj> like JEP-68?  Again, not something I feel
    hildjj> strongly about, but a sentance here may save us
    hildjj> a JEP later.

    lw> Personally, I see no point to this.  Command names
    lw> are not intended to be absolute; they have a
    lw> context, which is the responder.  Also, from
    lw> discussions both here and in the groupchat's,
    lw> there's a lot of subjective opinions on what even
    lw> the simple names "list" and "config" would really
    lw> mean.

Nod.  Let's leave that can of worms closed, then.

Joe Hildebrand

More information about the Standards mailing list