[JDEV] Questions about jabber:x:events

[Julian Missig]

On Wed, 2002-06-26 at 19:22, Sean Kirkby wrote:
> Hello,
>  
> I have a few questions I'm hoping someone can help with:
>  
> 1) Is the "id" attribute of a <message/> packet a required attribute?

Not yet at least.

>  
> 2) If not, and a client receives a <message/> packet with a <x
> xmlns=jabber:x:events><composing/></x> request in it, how shoudl the
> client handle the request?  It will not have a message ID to put in
the
> <id/> element for a "composing" event packet.  Should it just send the
> event with no ID?  Or not send the event at all?  And does the answer
to
> this question represent "conventional wisdom", "community consent", or
> is it part of the specification?

The <id/> element in jabber:x:event is required, so it's "conventional
wisdom" or "common sense" that the id attribute would be required in
this case. If the client doesn't send you an id attribute, you're free
to not send them back the event. Their client is broken, so they
shouldn't expect other clients to handle broken protocol.

>  
> 3) Is the "composing" event the only event that really supports the
> notion of "canceling the event"?  In other words, does it ever make
> sense to try to cancel any of the other three events?  Rather than
> "canceling" a "composing" event, wouldn't it make more sense to make
it
> two different events?  After all, if a user starts composing, and an
> event notification is sent, it really doesn't make sense to try to say
> "oops... actually, the user never really started composing... so
cancel
> that".  Rather, it would make more sense to have a "composing_start"
> event and a "composing_stop" event.  Am I off base here?

Yes, the composing event is the only one which can be canceled. The lack
of any event elements means the same as canceling the pending events...
in the future it may make more sense to be able to cancel the composing
event specifically, but as it currently stands, it's the only one you
can cancel.

>  
> 4) If "canceling" an event applies to more than the "composing" event
> (perhaps to future events not yet supported), does the current scheme
> for canceling events allow for this easily?  As far as I can tell, the
> event cancellation doesn't really identify an event to cancel.  Is the
> event cancelation supposed to apply only to the most recently received
> event, or is it only supposed to apply to composing events?

Composing.

http://www.jabber.org/jeps/jep-0022.html

Julian
-- 
email: julian at jabber.org
jabber:julian at jabber.org