[standards-jig] JEP-50 Sponsorship

Matthew A. Miller linuxwolf at outer-planes.no-ip.com
Tue Apr 22 18:50:01 UTC 2003

No worries on the supercites, it can get confusing (-:

In the recently released draft, I made it a MAY be suspicious.  If MUST
is acceptable, I'm more than willing to change to that (-:

Pub/sub is shaping up to be quite nice for this, but I agree that it
doesn't make sense to wait for JEP-0060.  JEP-0050 is not dependent upon
it, so why delay?

Please review the current JEP revision, and see if this acceptable
wording.  Both "Implementation Notes/Command Payload" and "Formal
Description/<command/> Element" mention this.

I did have a working xcommands lib and sample that helped drive the
current JEP.  From my experience, just using IQ-set didn't present any
additional challenges, and did help make implementing the flow for a
multi-stage command easier.  I just had to worry about which stage the
execution was at, not whether it was requesting or submitting the form. 
>From my experience with other environments like this, it proves to be
more efficient and not the big challenge others have.

This may be something that needs more implementation experience, so I
humbly request we let this JEP go to DRAFT before changing this (-:

ON CANCEL (x:data vs xcommands):
My general belief is that the xcommands "action" take precedence over
anything the payload may dictate.  In my opinion, this would be more
consistent for future considerations, although it can have an impact on
existing implementations (e.g. differences in processing <message/>
forms and xcommands forms).

I can go either way on this, though.  Anyone for breaking the tie? (-: 
I'll place into the JEP whichever is decided on this:
A)  <command/> type takes precedence over any payload considerations,
meaning that if there's no <command type='cancel'/>, the command is not
B)  x:data's container type is taken into consideration, which means
that a <x type='cancel'/> can cancel the command.

-  LW

On Tue, 2003-04-22 at 10:10, Joe Hildebrand wrote:
> (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.

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 mailing list