[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
thing.

    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