> On Mar 10, 2015, at 8:12 AM, Christian Ulrich <[email protected]> 
> wrote:
> 
> Thanks for clarifying. Do we allow a client to send an enable stanza
> before resource binding then? We should not, if we want to allow the
> first two options you mentioned.

I don't see a need to particularly restrict that ability since it's an App 
Client
that will be making the enable call, so if the app needs to have a resource 
association
it should wait until after binding.

At the least, a suggestion to wait until binding would be good, right?

> more details I came across: 
> The XEP defines the push notification field last-message-body. RFC 6120
> says:
> 
> "Multiple instances of the <body/> element MAY be included in a message
> stanza for the purpose of providing alternate versions of the same body,
> but only if each instance possesses an 'xml:lang' attribute with a
> distinct language value"
> 
> Quite a rare case I think, should the server just pick the first body or
> should it include all bodies like this:

Ah, right. That's going to get tricky very quickly, but I'm not seeing anything 
better than your
suggestion right now. 

> Is there a reason why jingle events (like in the old version) are not
> included in the field list?

The summary form is meant to be just that — a summary of information you will 
always want to
have in a push so you can keep counters and badges, etc, synced properly. Not 
everything needs
to be forced to fit into the summary form; you can include any other payload 
elements you wish.

I've (maybe incorrectly?) thought of the summary data to be 'passive' data. So 
I'm undecided how
Jingle would fit there yet, since it is more of a call-to-action that could 
need special treatment.

I am anticipating an update to http://xmpp.org/extensions/xep-0353.html to 
define how to use it
with push, which would cover this case.


> Could a server shutdown be a push event?

No reason why not. I'm not sure what you'd do with the information, but if 
that's interesting
to applications, then yeah.



- Lance

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to