Re: [Standards] UPDATED: XEP-0333 (Chat Markers)

[Spencer MacDonald]

Hi,
You are correct it's purely client based (although this wasn't originally the 
case) so determine support should be between 2 clients.
In regards to sending not sending an error, I just borrowed that from the 
delivery receipts XEP :-)
Regards
Spencer


_
From: Thijs Alkemade 
Sent: Wednesday, October 28, 2015 8:28 p.m.
Subject: Re: [Standards] UPDATED: XEP-0333 (Chat Markers)
To: XMPP Standards 


   
  On 28 okt. 2015, at 16:50, XMPP Extensions Editor < 
edi...@xmpp.org> wrote:
 Version 0.2.1 of XEP-0333 (Chat Markers) has been released. 
 
Abstract: This specification describes a solution of marking the last received, 
displayed and acknowledged message in a chat. 
 
Changelog: Fixing typo ("cannot" repeated twice) (JC Brand). (XEP Editor (mam)) 

 
Diff:  http://xmpp.org/extensions/diff/api/xep/0333/diff/0.2/vs/0.2.1 
 
URL:  http://xmpp.org/extensions/xep-0333.html 
  
I tried to read this specification today, and it left me rather 
confused. 
   From the introduction it is not clear to me how Chat Sate 
Notifications +Carbons is insufficient.  
 §4 has two examples where the client queries a server for support, 
but the entire specification reads as if it only applies to 
clients. 
 Lastly, it says in §6: 
 > If recipient does not support the Chat Markers protocol it 
SHOULD NOT return an error. 
 While it does sound like a very sensible requirement, extensions 
shouldn't be able to set requirements for all implementions that 
don't support it. 
 Regards Thijs

Re: [Standards] Chat markers and pagination

[Spencer MacDonald]

It is assumed that you either load the last X Messages or you load all of
them.

Typically if you sign in on a client that has no (previous) cache, you
would only download the last few messages e.g. 25 per chat, then the user
can manually download messages prior to that.

Spencer

On Thu, Dec 4, 2014 at 1:50 AM, priya v  wrote:

> How would chat markers work when they are used in the context of
> pagination? Please consider the following use case to get a better
> understanding of my question-
>
> Assume there are 50 messages stored in a user's archive store. Of which a
> marker of type 'delivered' is received for the 25th message. Assume an XMPP
> client queried for the first 10 messages from the user's store.
>
> Should the server send the 25th marker even if the 25th message is not
> sent?
> Messages from 1 to 10 might have been read without any markers being sent.
>
> The spec doesn't talk of cases where markers are used in conjunction with
> RSM. How do we handle such cases?
>

Re: [Standards] SMS/Email Forwarding of Messages

[Spencer MacDonald]

Hi Steffen,

I was at the summit and also thought that it could be added to the push 
notification XEP, but for SMS/Email you might want to:

- Know what telephone number or email address the message was forwarded on to.
- Know if the message has been sent/received/opened
- Opt in/Out of paying for forwarding (in the case of SMS).

So although it can be just another end point, I think you still need additional 
logic when compared to push notifications.

Regards

Spencer

On 17 Feb 2014, at 13:51, Steffen Larsen  wrote:

> I think you might look at the stuff we were discussing at the XMPP summit, 
> namely push notifications.
> Lance stout have begun doing a XEP for this: 
> http://legastero.github.io/customxeps/extensions/push.html
> 
> It can prob. be used for SMS and email as well. Just another endpoint. :-)
> 
> /Steffen
> 
> 
> On 17 Feb 2014, at 14:47, Spencer MacDonald 
>  wrote:
> 
>> Is there any XEP that covers a message getting forwarded using another 
>> transport e.g. SMS, Email?
>> 
>> If not would there be any interest in making a standard one?
>> 
>> My personal use case is if the recipient is offline, the message can be 
>> forward to their phone as an SMS.
>> 
>> Regards
>> 
>> Spencer
> 

[Standards] SMS/Email Forwarding of Messages

[Spencer MacDonald]

Is there any XEP that covers a message getting forwarded using another 
transport e.g. SMS, Email?

If not would there be any interest in making a standard one?

My personal use case is if the recipient is offline, the message can be forward 
to their phone as an SMS.

Regards

Spencer

Re: [Standards] MAM IDs

[Spencer MacDonald]

I just used XEP-0202 to get around the wrong time issue.

I have only been to dealing with storing messages that people type and send, so 
the chance of multiple messages in (very) quick succession wasn’t an issue for 
me. 

Regards

Spencer


On 17 Feb 2014, at 10:55, Thijs Alkemade  wrote:

> 
> On 17 feb. 2014, at 11:26, Kevin Smith  wrote:
> 
>> In MAM, stanzas stored get stamped with a MAM ID by the entity that
>> stored them, and entities receiving them then receive this.
>> 
>> So a general question - are these useful? Are clients going to ignore
>> them and just request all history since they last requested it anyway?
>> 
>> /K
> 
> Because querying by date range is unreliable, and should be avoided wherever
> possible. The client's and the server's clock could be minutes apart and even
> if they were synchronized then multiple messages arriving in the same second
> can lead to difficult edge cases.
> 
> I'd much rather query by the UUID injected into a message than by the
> approximate datestamp.
> 
> Thijs

Re: [Standards] MAM IDs

[Spencer MacDonald]

If you mean the archived element:

 

I personally have not found any need for it.

Regards

Spencer

On 17 Feb 2014, at 10:26, Kevin Smith  wrote:

> In MAM, stanzas stored get stamped with a MAM ID by the entity that
> stored them, and entities receiving them then receive this.
> 
> So a general question - are these useful? Are clients going to ignore
> them and just request all history since they last requested it anyway?
> 
> /K

Re: [Standards] Discussions at the summit

[Spencer MacDonald]

I assume only certain people can edit the page (or I missed the button)?

It would be good to add:
Push Notification XEP
Stanza Throttling/Buffering

Both of which has been discussed on the list, but didn’t reach a conclusion.

Regards

Spencer

On 27 Jan 2014, at 10:42, Kevin Smith  wrote:

> Hi folks,
>  Just a quick reminder for those attending the summit. If there are
> things you'd like to have on the agenda, please pop them on
> http://wiki.xmpp.org/web/Summit_15#Agenda - and if everyone can have a
> look at what's there before going and work out what stuff you
> particularly want to be involved in discussions for it should make
> planning the agenda when we get there much faster and easier.
> 
> Ta,
> /K

Re: [Standards] Push notification XEP

[Spencer MacDonald]

The question also arises if the XEP should allow you to enable/disable 
different types of push notifications e.g. Chat Message, MUC Invites etc or 
just be for setting your token(s). 

Regards

Spencer


On Tuesday, 21 January 2014 at 16:52, Matthew Wild wrote:

> Hi Daniele,
> 
> On 21 January 2014 09:58, Daniele Ricci  wrote:
> > Hello list,
> > I was thinking of writing a XEP for sending a sender ID (Google Cloud
> > Messaging) or a device token (Apple Push Notification Service) or any
> > other push notification service token (that is, a generic one) to the
> > server.
> > Almost all push notification services works the same way: the server
> > provides a provider ID to the client and the client provides a device
> > token to the server.
> > 
> 
> 
> We discussed precisely this at the last summit. Nobody has actually
> written a XEP yet, it would be great if you're able to write one :)
> 
> Your approach is fine, the only difference I see is that you have a
> different JID for each service, whereas we were considering a single
> push service that accepted requests from all types of devices (e.g.
> push.example.com). I have to say I prefer this "all in one" approach,
> but feel free to make a case for splitting them up.
> 
> Regards,
> Matthew
> 
> 

Re: [Standards] Proposed XMPP Extension: User Time Zone

[Spencer MacDonald]

Hi Peter,  

It is, but I have often wanted to put something along the lines of "Steve is in 
Califonia, he is 8 hours behind you". I could in theory publish the location 
and time zone independently but this isn't great if they actually linked.  

Regards

Spencer


On Wednesday, 4 December 2013 at 15:34, Peter Waher wrote:

> Hello Spencer.
>   
> Isn’t time zone already defined in XEP-0082?
> http://xmpp.org/extensions/xep-0082.html#sect-id310737
>   
> That is, if specifying a timestamp, XEP-0082 requires a Time Zone definition 
> according to the DateTime profile.
>   
> Best regards,
> Peter Waher
>   
> From: Spencer MacDonald [mailto:spencer.macdonald.ot...@gmail.com]  
> Sent: den 4 december 2013 06:27
> To: XMPP Standards
> Subject: Re: [Standards] Proposed XMPP Extension: User Time Zone  
>   
> Although I agree that this should be an XEP in its own right, the user's 
> timezone is often tied to their location so would it also be useful to add a 
> timezone element to XEP-0080: User Location as well?
>   
>  
> Regards
>  
>   
>  
> Spencer
>  
>  
>   
> On Tue, Dec 3, 2013 at 8:50 PM, XMPP Extensions Editor  (mailto:edi...@xmpp.org)> wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>  
> Title: User Time Zone
>  
> Abstract: This specification defines a payload format for communicating 
> information about a user's time zone. The payload format is typically 
> transported using the personal eventing protocol, a profile of XMPP 
> publish-subscribe specified in XEP-0163.
>  
> URL: http://xmpp.org/extensions/inbox/peptzo.html
>  
> The XMPP Council will decide in the next two weeks whether to accept this 
> proposal as an official XEP.  
>   
>  
>  
>  
>  

Re: [Standards] Proposed XMPP Extension: User Time Zone

[Spencer MacDonald]

Although I agree that this should be an XEP in its own right, the user's
timezone is often tied to their location so would it also be useful to add
a timezone element to XEP-0080: User Location as well?

Regards

Spencer


On Tue, Dec 3, 2013 at 8:50 PM, XMPP Extensions Editor wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: User Time Zone
>
> Abstract: This specification defines a payload format for communicating
> information about a user's time zone. The payload format is typically
> transported using the personal eventing protocol, a profile of XMPP
> publish-subscribe specified in XEP-0163.
>
> URL: http://xmpp.org/extensions/inbox/peptzo.html
>
> The XMPP Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
>
>

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

On Tue, Oct 29, 2013 at 5:19 PM, Dave Cridland  wrote:

> Right. I think I have just about enough for a proposal; unless anyone else
> is working on it I'll scribble out a buffer/hush/discard proposal.
>

I would of been happy to do a buffer proposal, but it sounds like you want
to role the 3 solutions into one XEP, so il leave it in your capable hands.

Spencer

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

On Tue, Oct 29, 2013 at 4:44 PM, Peter Saint-Andre wrote:

> I see two things:
>
> 1. Hey, wake up, you've got some data buffered up at the server! (use
> push notifications for this)
>

> 2. Ah, great, you're awake -- here's some data for you. (use XMPP for
> this)
>
> Is that disallowed by Apple policy?
>
> Peter
>


As long as you don't send too many stanza's over the TCP socket while the
app is in the background your fine.

To be clear, Push Notifications don't wake the app up unless the user acts
upon them.

Spencer

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

On Tue, Oct 29, 2013 at 3:44 PM, Peter Saint-Andre wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/29/13 8:03 AM, Spencer MacDonald wrote:
> > Yeah, thats what I have done without the jingle exception (I use
> > SIP for VoIP).
>
> I'd be curious to hear what you think about this document about
> guidelines for dual-stack SIP/XMPP clients:
>
> https://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/
>
> It's been approved for publication as an RFC, but if there's something
> horribly wrong in there I'd appreciate hearing about it.
>

I had a brief look previously but il give it another once over :)


>
> > I think a simple buffer protocol would do, with a way of clients
> > specifying what type of packets (like SIFT) which would cause a
> > server flush... but due to the limitations on iOS that would
> > probably only be Jingle.
>
> Is there something in SIFT that doesn't meet the requirements? For
> instance, does it need to say that filtered / intercepted stanzas are
> indeed buffered?


Thats correct, compared to SIFT I want:

- All stanzas to be buffered by the server
- On receiving an "allowed" element the server should flush its buffer upto
and including that stanza, opposed to just letting that stanza through.

Spencer

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

On Tue, Oct 29, 2013 at 3:16 PM, Peter Saint-Andre wrote:

> Does this mean that all messaging apps are disallowed? That doesn't
> actually seem to be the case.
>
> Peter
>

They all use Push Notifications to notify the user of new messages. If they
also offer VoIP they are doing what I suggested or disconnecting from the
XMPP Server when the app is put into the background.

Regards

Spencer

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

Yeah, thats what I have done without the jingle exception (I use SIP for
VoIP).

I think a simple buffer protocol would do, with a way of clients specifying
what type of packets (like SIFT) which would cause a server flush... but
due to the limitations on iOS that would probably only be Jingle.

Regards

Spencer


On Tue, Oct 29, 2013 at 12:40 PM, Dave Cridland  wrote:

> On Tue, Oct 29, 2013 at 12:29 PM, Spencer MacDonald <
> spencer.macdonald.ot...@gmail.com> wrote:
>
>>
>>> 2) You will no longer receive VoIP Calls, which is the real purpose of
>>>> the background socket.
>>>>
>>>>
>>> Wouldn't mobile push solutions handle that if properly integrated?
>>>
>>
>> The issue is that push notifications take anywhere between 1 and 20
>> seconds to reach a device under normal circumstances, so by the time the
>> recipient sees the notification, launches the app, the app connects to the
>> server etc the callee has probably hung up.
>>
>>
> Oh. That's a bit pants, then.
>
> It'd be easier to solve these problems if the overriding concerns were
> technical, of course, but it's looking like you'll need to handle a case
> where pretty much all traffic is fully buffered, except for Jingle
> session-initiate.
>
> We can call it Broken Apple Mode.
>
> Dave.
>

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

>
>
> 2) You will no longer receive VoIP Calls, which is the real purpose of the
>> background socket.
>>
>>
> Wouldn't mobile push solutions handle that if properly integrated?
>

The issue is that push notifications take anywhere between 1 and 20 seconds
to reach a device under normal circumstances, so by the time the recipient
sees the notification, launches the app, the app connects to the server etc
the callee has probably hung up.

Spencer

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

The other 2 problems with your app getting killed is:

1) Your presence will be unavailable, so people are potentially less likely
to contact you.
2) You will no longer receive VoIP Calls, which is the real purpose of the
background socket.

Maybe we are talking about 2 different problems with 2 different solutions?

Spencer


On Tue, Oct 29, 2013 at 11:03 AM, Dave Cridland  wrote:

>
>
>
> On Tue, Oct 29, 2013 at 9:02 AM, Spencer MacDonald <
> spencer.macdonald.ot...@gmail.com> wrote:
>
>> I think your under estimating the amount of messages somebody receives in
>> an active chat, especially when some people tend to split their messages up
>> like so:
>>
>
> I try not to talk to such people.
>
> But seriously, while it could easily be that my patterns are different, my
> message traffic is usually way lower than 3/min. I used to graph such
> things, but based on simple counting it doesn't seem that high.
>
>
>> Moreover if your mobile app has a Desktop counterpart you might end up
>> being a participant in one or more group chats, like you said could end up
>> generating a lot of traffic.
>>
>>
> Right, being able to distinguish from important messages and background
> traffic in a MUC environment is hard, of course, but possible - the clients
> manage to identify the user's nickname in messages, for instance, so
> therefore so could the server.
>
>
>> Also (iOS specific again, sorry) your not allowed to use the background
>> socket for "messages" anyway, thats what push notifications are for. Also
>> the user is not informed in any way that the app has been killed so they
>> wouldn't bother to relaunch it, thus not resuming the stream until the next
>> time they want to send a message.
>>
>>
> No, the user wouldn't be informed the app has been killed, but would see a
> notification that a message is deliverable when offline.
>
> Dave.
>

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

I think your under estimating the amount of messages somebody receives in
an active chat, especially when some people tend to split their messages up
like so:

Message 1:
Hi

Message 2:
How are you

Message 3:
?

Message 4:
:)

Moreover if your mobile app has a Desktop counterpart you might end up
being a participant in one or more group chats, like you said could end up
generating a lot of traffic.

Also (iOS specific again, sorry) your not allowed to use the background
socket for "messages" anyway, thats what push notifications are for. Also
the user is not informed in any way that the app has been killed so they
wouldn't bother to relaunch it, thus not resuming the stream until the next
time they want to send a message.

Regards

Spencer


On Mon, Oct 28, 2013 at 9:46 PM, Dave Cridland  wrote:

> On Mon, Oct 28, 2013 at 7:57 PM, Spencer MacDonald <
> spencer.macdonald.ot...@gmail.com> wrote:
>
>> I have used a custom implementation that just had the following commands:
>>
>> - Enable (enable the buffer)
>> - Flush (flush the buffer)
>> - Disable (disable the buffer, which also flushes it)
>>
>> It worked great, but I wasn't using any time sensitive XEPs like Jingle
>> that you would want to let through.
>>
>> The major issue on iOS is if the device "wakes up" more than 15 times in
>> 5 mins your app would get killed, so letting through "important" messages
>> still wouldn't be a good idea.
>>
>>
> Right; the google:queue implementation I once wrote, in a past life,
> buffered up only presence. IQ, and messages, came through - but it was
> clever enough to figure out that local PEP at least was bufferable.
>
> I suspect though that most people would handle less than 3 messages a
> minute on mobile for at least most of the time. I only get that kind of
> level on desktop if I'm in a MUC or two.
>
> Even if the client was killed, the combination of mobile push and XEP-0198
> should make that fairly painless, too.
>
> Dave.
>

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

I have used a custom implementation that just had the following commands:

- Enable (enable the buffer)
- Flush (flush the buffer)
- Disable (disable the buffer, which also flushes it)

It worked great, but I wasn't using any time sensitive XEPs like Jingle
that you would want to let through.

The major issue on iOS is if the device "wakes up" more than 15 times in 5
mins your app would get killed, so letting through "important" messages
still wouldn't be a good idea.

Regards

Spencer


On Mon, Oct 28, 2013 at 6:05 PM, Dave Cridland  wrote:

> On Mon, Oct 28, 2013 at 5:54 PM, Peter Waher wrote:
>
>> > How do we define "important"? There's the challenge. :-)
>>
>> True. But not only "how", but also "where" it is defined. The received
>> can define what it wants, the xmpp server can define what to forward under
>> certain conditions, and the sender can define the priority of a message.
>>
>> Many network protocols have solved this by letting the sender determine a
>> priority or QoS level for each message. The sender normally knows if
>> something is "important" (for instance an alarm, or a call or control
>> command) or "normal" (informational message) or "less important" (recurrent
>> status update), for instance, and so no complex logic for this is required.
>>
>> An objection could be made that an application could then choose to send
>> all messages as "important" messages, overriding any throttling logic. But
>> in practice, this would be counterproductive since users would quickly find
>> out what service/device/address works badly and stop using it or
>> unfriending misbehaving contacts.
>>
>> The above solution could then hypothetically be complemented by a simple
>> subscription mechanism on the client, or an automatic rule on the xmpp
>> server determining what messages to forward and when, and perhaps also with
>> bandwidth limits on different types of messages, and if messages not being
>> forwarded should be treated as offline messages or thrown away (based on
>> message priority).
>>
>
> I think this is XEP-0334, Messaging Processing Hints. Or ought to be, at
> any rate.
>

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

The difference between Sift and what people want on iOS, is for the stanzas
to be queued by the server and not discarded.

Having a filter so that certain Stanza's like Jingle get through would be
more ideal though.

Spencer


On Mon, Oct 28, 2013 at 3:50 PM, Kevin Smith  wrote:

>
>
>
> On Mon, Oct 28, 2013 at 3:49 PM, Spencer MacDonald <
> spencer.macdonald.ot...@gmail.com> wrote:
>
>> I missed that XEP-0273 as it is Deferred,
>>
>> Is it Deferred for any particular reason or just because of inactivity?
>>
>
> Inactivity is the only reason XEPs get deferred.
>
> /K
>

Re: [Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

I missed that XEP-0273 as it is Deferred,

Is it Deferred for any particular reason or just because of inactivity?

Regards

Spencer


On Mon, Oct 28, 2013 at 3:47 PM, Peter Waher wrote:

>  Hello Spencer
>
> ** **
>
> As Joachim mentioned, there is interest from the Internet of Things (IoT)
> community to create such a XEP. In fact, it is already planned because
> there’s a need, but it is yet to be written. Anybody interested in
> co-authoring such a XEP is welcome to contact me.
>
> ** **
>
> The envisioned XEP however is not IOS specific, but rather concerns
> battery-powered sensors, but can be applied to sensors in resource
> constrained networks (where bandwidth is constrained). The same solutions
> can be applied in the IOS case you mentioned, since it can be seen as a
> resource constrained device, when the application runs in the background.*
> ***
>
> ** **
>
> Peter Saint-André mentioned that the deferred XEP 0273 could solve part of
> this issue, by permitting the filtering of certain messages.
>
> ** **
>
> Forwarding of offline stanzas (XEP-0160) can also be used. I.e. the
> bandwidth can be controlled by the device, using the presence as an
> indication when the server can send information. (Here battery powered
> sensors often go into sleep mode and wake up regularly to perform a task.
> They can only receive messages when awake.)
>
> ** **
>
> Other solutions can be envisioned, for instance using presence=away to
> signal clients restricting them to send important messages only, queuing
> not as important messages for later when online, etc.
>
> ** **
>
> Ideas are welcome.
>
> ** **
>
> Best regards,
>
> Peter Waher
>
> ** **
>
> ** **
>
> *From:* Spencer MacDonald [mailto:spencer.macdonald.ot...@gmail.com]
> *Sent:* den 27 oktober 2013 13:17
> *To:* XMPP Standards
> *Subject:* [Standards] Standard for Throttling/Queueing Stanzas
>
> ** **
>
> I have observed from the XMPPFramework mailing list and Github issues,
> that one of the biggest problems that iOS Developers have with including
> XMPP (alongside VoIP) in their iOS apps, is that their apps get terminated
> for receiving to much data while in the background.
>
> ** **
>
> There are proprietary solutions that allow an XMPP client to inform the
> XMPP Server that the app is going to be put in the background. The XMPP
> Server then queues the stanzas until the client in with the XMPP Server,
> which on iOS is less than or equal to 10 minutes. Some solutions also
> filter out presence packets so only the most recent one is queued for each
> jid.
>
> ** **
>
> I appreciate that the problem is iOS specific, but the solution can be
> generic.
>
> ** **
>
> Is this something that should be incorporated into an XEP? or is there
> already a solution for this issue?
>
> ** **
>
> Regards
>
> ** **
>
> Spencer
>

[Standards] Standard for Throttling/Queueing Stanzas

[Spencer MacDonald]

I have observed from the XMPPFramework mailing list and Github issues, that
one of the biggest problems that iOS Developers have with including XMPP
(alongside VoIP) in their iOS apps, is that their apps get terminated for
receiving to much data while in the background.

There are proprietary solutions that allow an XMPP client to inform the
XMPP Server that the app is going to be put in the background. The XMPP
Server then queues the stanzas until the client in with the XMPP Server,
which on iOS is less than or equal to 10 minutes. Some solutions also
filter out presence packets so only the most recent one is queued for each
jid.

I appreciate that the problem is iOS specific, but the solution can be
generic.

Is this something that should be incorporated into an XEP? or is there
already a solution for this issue?

Regards

Spencer

Re: [Standards] Re-escalating update of XEP-0313: MAM

[Spencer MacDonald]

The Purge API is something that I have been looking for, but the spec
doesn't appear to have any way of finding out what messages have been
purged from the archive, which means the local cache cannot be synced up
with archive without fetching it all.

Spencer


On Thu, Oct 10, 2013 at 2:27 PM, Matthew Wild  wrote:

> Hi Valérian,
>
> On 10 October 2013 05:56, Valérian Saliou 
> wrote:
> > Hello everyone,
> >
> > I'm re-escalating my request for XEP-0313 update, which purpose is to
> bring
> > a way to change the user's message archiving preferences (something very
> > basic, so that we keep things simple and respect the philosophy of MAM
> which
> > is to remove the burden of previous message archiving XEPs).
>
> Sorry about the delay in processing your contribution. I've not had
> much time to work on XEP stuff the past couple of months.
>
> > You can find the Web browser-viewable version of the updated
> specification
> > there:
> >
> https://demo.frenchtouch.pro/valerian.saliou/xmpp/extensions/xep-0313.html
> > Also, my previous update request from August on this mailing list:
> > http://mail.jabber.org/pipermail/standards/2013-August/027873.html
>
> I had some questions about it from the other day which I can't recall
> right now (and I'm going out). I was going to email you at the weekend
> to see how your implementation of your changes was working out.
>
> Oh, I think one of my questions was that it might make more sense to
> be able to delete by id (individual message), or even range of ids.
> This is a bit awkward to implement, as it doesn't really make sense to
> use RSM for deletion IMHO - but that's how access-by-id is
> implemented. Thoughts?
>
> Also in my todo queue are updates related to message hints. After
> deletion and hints are in, I think we're ready to push for draft!
>
> Regards,
> Matthew
>

Re: [Standards] UPDATED: XEP-0322 (Efficient XML Interchange (EXI) Format)

[Spencer MacDonald]

I hate to be pernickety, but is there a reason why the tag names are camel
case unlike other xeps e.g. downloadSchemaResponse I would expect to be
download-schema-response

Regards

Spencer


On Thu, Jul 25, 2013 at 2:24 PM, XMPP Extensions Editor wrote:

> Version 0.3 of XEP-0322 (Efficient XML Interchange (EXI) Format) has been
> released.
>
> Abstract: This specification describes how EXI compression can be used in
> XMPP networks.
>
> Changelog: [See revision history] (pw, yd)
>
> Diff: http://xmpp.org/extensions/diff/api/xep/0322/diff/0.1/vs/0.3
>
> URL: http://xmpp.org/extensions/xep-0322.html
>
>

Re: [Standards] XEP-0084: User Avatar and Different Sized Images

[Spencer MacDonald]

These are similar issues to what I have been seeing, XEP-0084 seems like a
good solution for me regardless of wether I can have images of multiple
sizes.

Spencer


On Wed, Jul 24, 2013 at 11:19 AM, Simon Tennant wrote:

> I read in the spec that:
>
> *It is intended that this specification will supersede both IQ-Based
> Avatars <http://xmpp.org/extensions/xep-0008.html> 
> [6<http://xmpp.org/extensions/xep-0084.html#nt-id208472>]
> and vCard-Based Avatars <http://xmpp.org/extensions/xep-0153.html> 
> [7<http://xmpp.org/extensions/xep-0084.html#nt-id208494>]
> once the PEP subset of XMPP publish-subscribe is implemented and deployed
> widely enough.*
>
> One of the reasons I never turn on vCard support for servers is that it
> opens up a can of worms -
>
> - a user fills out their vCard or edits their Avatar and drags over a
> photo of themselves that is 7MB.
> - another user's phone client is now stuck trying to download a huge image
> - likewise, as a server admin I can't set an upper bound on the image size.
>
> S.
>
>
> On 24 July 2013 11:16, Spencer MacDonald <
> spencer.macdonald.ot...@gmail.com> wrote:
>
>> Hi,
>>
>> I was wondering if it is "allowed" to have multiple sized images (width
>> and height) in a single node? e.g. a thumbnail and full scale image.
>>
>> Section 5 of the XEP specifies that you can have different formats, but I
>> want to have the same format but at different sizes.
>>
>> Regards
>>
>> Spencer
>>
>
>
>
> --
> Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours:
> goo.gl/tQgxP
>

[Standards] XEP-0084: User Avatar and Different Sized Images

[Spencer MacDonald]

Hi,

I was wondering if it is "allowed" to have multiple sized images (width and
height) in a single node? e.g. a thumbnail and full scale image.

Section 5 of the XEP specifies that you can have different formats, but I
want to have the same format but at different sizes.

Regards

Spencer

Re: [Standards] Comments on Chat Markers

[Spencer MacDonald]

I have updated the XEP based on the feedback.

Regards

Spencer


On Sun, Jul 7, 2013 at 9:58 AM, Spencer MacDonald <
spencer.macdonald.ot...@gmail.com> wrote:

>  No your correct, I was trying to stick to the naming from other XEPs but
> it doesn't quite fit.
>
> Regards
>
> Spencer
>
> On Sunday, 7 July 2013 at 08:57, Kevin Smith wrote:
>
> On Sat, Jul 6, 2013 at 8:56 PM, Spencer MacDonald
>  wrote:
>
> Before I send in my update with the above changes, I am think about adding
> a
> requirement that all messages that can be marked, should have an "allowed"
> child element.
>
> 
>
> This means that messages containing only Chat States, Delivery Receipts etc
> are not included in Chat Markers and this will network traffic for
> redundant
> Chat Markers.
>
> Does anyone have an opinion on this?
>
>
> Sounds reasonable - although I'm not sure 'allowed' represents what
> you're trying to express (or I didn't understand). Would 'markable' be
> better?
>
> /K
>
>
>


%ents;
]>



  Chat Markers
  This specification describes a solution of marking the last received, displayed and acknowledged message in a chat.
  
This XMPP Extension Protocol is copyright (c) 1999 - 2013 by the XMPP Standards Foundation (XSF).
Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://www.xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).
  
  
  ProtoXEP
  Standards Track
  Standards
  Council
  
XMPP Core
XEP-0001
  
  
  
  NOT_YET_ASSIGNED
  
Spencer
MacDonald
i...@spencermacdonald.com
i...@spencermacdonald.com
  
  
0.0.4
2013-07-06
sdm

  Noted that Chat Markers is a heuristic solution.
  Added markable element.

  
  
0.0.3
2013-06-20
sdm

  Changed read Chat Marker to displayed.
  Removed stamp from Chat Marker.
  Added thread to Chat Marker.
  Changed namespace to allow for versioning.

  
  
0.0.2
2013-06-11
sdm
Change to a message based protocol.
  
  
0.0.1
2013-05-24
sdm
First draft.
  


  The concept of delivery and read receipts has been popularised by other messaging services such as iMessage, Google Hangouts and Blackberry Messenger. 
  These services provide a visual indication of when a message has been delivered to a

Re: [Standards] Comments on Chat Markers

[Spencer MacDonald]

No your correct, I was trying to stick to the naming from other XEPs but it 
doesn't quite fit. 

Regards

Spencer


On Sunday, 7 July 2013 at 08:57, Kevin Smith wrote:

> On Sat, Jul 6, 2013 at 8:56 PM, Spencer MacDonald
>  wrote:
> > Before I send in my update with the above changes, I am think about adding a
> > requirement that all messages that can be marked, should have an "allowed"
> > child element.
> > 
> > 
> > 
> > This means that messages containing only Chat States, Delivery Receipts etc
> > are not included in Chat Markers and this will network traffic for redundant
> > Chat Markers.
> > 
> > Does anyone have an opinion on this?
> 
> Sounds reasonable - although I'm not sure 'allowed' represents what
> you're trying to express (or I didn't understand). Would 'markable' be
> better?
> 
> /K 

Re: [Standards] Comments on Chat Markers

[Spencer MacDonald]

Before I send in my update with the above changes, I am think about adding
a requirement that all messages that can be marked, should have an
"allowed" child element.

 

This means that messages containing only Chat States, Delivery Receipts etc
are not included in Chat Markers and this will network traffic for
redundant Chat Markers.

Does anyone have an opinion on this?


On Thu, Jul 4, 2013 at 1:39 PM, Spencer MacDonald <
spencer.macdonald.ot...@gmail.com> wrote:

> Hi Kevin,
>
> Thanks for the feedback,
>
> As I mentioned on another thread, I see no reason why we shouldn't add a
> 'displayed'/'read' element to XEP-0184, in addition to Chat Markers.
>
> I think as you suggested that it would be wise to point out that Chats
> Markers are only heuristics, not having to ack every message with a receipt
> is one of the major benefits of using Chat Markers so I wouldn't want to go
> down this road.
>
> Regards
>
> Spencer
>
>
> On Thu, Jul 4, 2013 at 11:45 AM, Kevin Smith  wrote:
>
>> After reviewing the Chat Markers proposal for Council, I have two main
>> concerns.
>>
>> 1) It's not clear to me that by adding a  equivalent to 184,
>> using MAM and chat states that we wouldn't have a simpler solution
>> with more re-use of existing paradigms. This comment isn't blocking.
>>
>> 2) It seems to me that this proposal is providing users with the
>> highest assurance of delivery ("This message has been read and
>> acknowledged by the user"), when it's possible that some of the
>> acknowledged messages were never delivered. This seems serious to me
>> in situations like:
>>
>>  Something terrible has happened, please send help.
>> [S2S blips, message gets lost]
>>  There's high winds here.
>> [S2S is back, message gets delivered]
>> User B now acknowledges the 'high winds' message as read.
>> Because of the 'up to this point' nature of the proposal, User A has
>> now had it acknowledged that User B has read the message about needing
>> to send assistance.
>>
>> There seem to be multiple ways to address this - one is to use an
>> approach more like 184, with per-message acks. Another is to say that
>> this proposal requires reliable transport, and that every message
>> needs to have 184 as well as chat markers in order for the markers to
>> be believed. Another is to put a banner across the top of the chat
>> markers spec saying that the acks it provides are only heuristic and
>> can't be used to assure users of messages being delivered or read.
>>
>> I think it's worth addressing this somehow, using one of the above
>> suggestions or some other, before this is published as implementation
>> as-is could conceivably lead to fatal misunderstandings in some of the
>> situations XMPP gets used.
>>
>> /K
>>
>
>

Re: [Standards] Comments on Chat Markers

[Spencer MacDonald]

Hi Kevin,

Thanks for the feedback,

As I mentioned on another thread, I see no reason why we shouldn't add a
'displayed'/'read' element to XEP-0184, in addition to Chat Markers.

I think as you suggested that it would be wise to point out that Chats
Markers are only heuristics, not having to ack every message with a receipt
is one of the major benefits of using Chat Markers so I wouldn't want to go
down this road.

Regards

Spencer


On Thu, Jul 4, 2013 at 11:45 AM, Kevin Smith  wrote:

> After reviewing the Chat Markers proposal for Council, I have two main
> concerns.
>
> 1) It's not clear to me that by adding a  equivalent to 184,
> using MAM and chat states that we wouldn't have a simpler solution
> with more re-use of existing paradigms. This comment isn't blocking.
>
> 2) It seems to me that this proposal is providing users with the
> highest assurance of delivery ("This message has been read and
> acknowledged by the user"), when it's possible that some of the
> acknowledged messages were never delivered. This seems serious to me
> in situations like:
>
>  Something terrible has happened, please send help.
> [S2S blips, message gets lost]
>  There's high winds here.
> [S2S is back, message gets delivered]
> User B now acknowledges the 'high winds' message as read.
> Because of the 'up to this point' nature of the proposal, User A has
> now had it acknowledged that User B has read the message about needing
> to send assistance.
>
> There seem to be multiple ways to address this - one is to use an
> approach more like 184, with per-message acks. Another is to say that
> this proposal requires reliable transport, and that every message
> needs to have 184 as well as chat markers in order for the markers to
> be believed. Another is to put a banner across the top of the chat
> markers spec saying that the acks it provides are only heuristic and
> can't be used to assure users of messages being delivered or read.
>
> I think it's worth addressing this somehow, using one of the above
> suggestions or some other, before this is published as implementation
> as-is could conceivably lead to fatal misunderstandings in some of the
> situations XMPP gets used.
>
> /K
>

Re: [Standards] Proposed XMPP Extension: Chat Markers

[Spencer MacDonald]

I have (slightly) updated my XEP based on feedback:

I have changed the element name read to displayed.
I have removed the stamp attribute (in practise it was confusing).
I have added a thread attribute.
I have changed the namespace to urn:xmpp:chat-markers:0 to allow for
versioning.

Regards

Spencer



On Fri, Jun 21, 2013 at 11:20 PM, David Laban  wrote:

> On Wed, 2013-06-19 at 20:42 +0100, Matthew Wild wrote:
> > On 18 June 2013 11:51, Spencer MacDonald
> >  wrote:
> > > Would it be possible to add "archive indicators" to XEP-0313 to solve
> my
> > > "messages with no body are not archived issue"?.
> > >
> > > Maybe just adding  as a child of the
> > > message?
> >
> > I've been thinking about this a bit. Since the issue first came up,
> > I've been wondering if there are alternatives to the "no-body" rule.
> > The problem is that the rule is 95% correct, but when it isn't it's
> > not very helpful.
> >
> > I noted that XEP-0280 (Carbons) has a similar issue, but has an
> > explicit flag (the  element) rather than attempting to come
> > up with any such rules.
> >
> > I've written a small proto-XEP that might be able to unify such flags:
> > http://matthewwild.co.uk/uploads/message-processing-hints.html
> >
> > With this we could either remove the no- rule, store by default
> > and use no-store. Or we can keep it and add a 'store' hint (this one
> > might be easier but feels backwards to me in the grand scheme of
> > things).
> >
>
> > Thoughts?
> >
> Since xep-0079 Advanced Message Processing seems extensible and
> discoverable, with well-defined "not implemented" cases, I'm just going
> to use it like a hammer and treat everything like a nail. If
> message-processing-hints ends up with a better syntax for these things,
> awesome.
>
> For your Example 1, could we use:
> 
> 
> 
> 
>
> Your mod_carboncopy and mod_mam implementations could advertise support
> for this by setting the following features (the client would need to
> query both the local and remote servers before relying on its amp rules
> applying though):
>
> (  var='
> http://jabber.org/protocol/amp?action=drop&condition=deliver&value=stored'/
> >
> OR NOT
> ( or ))
> AND (
>  var='
> http://jabber.org/protocol/amp?action=drop&condition=match-resource&value=other'/
> >
> OR NOT  )
>
> (not sure what clients should do if these conditions aren't met though)
>
>
> For the "please store me even though I have no body" case, if a message
> is tagged with  and there is no matching rule to cause 'drop', can
> we infer that the client understands AMP and would have told us to drop
> it if storing wasn't appropriate? If so, there's your "please store me"
> tag.
>
>
>
> Also, for the reliable message delivery case[1], when the remote user's
> server supports  var='
> http://jabber.org/protocol/amp?action=confirm&condition=deliver&value=stored'/>
> and ,
> when you send:
> 
> 
> 
>
> and the *remote user's* server doesn't reply with:
> 
> 
>
> within a reasonable time, then the local user's client should alert the
> user, and ask if a re-send is desired, or if the message should be
> cancelled using something like xep-0308 [2].
>
> This doesn't guarantee that the remote *client* supports MAM (Is that
> turd worth polishing? Suggestions welcome.) but if we added a
> client-side  to mean "I promise
> that I have checked my message archive and notified my user about all
> pending messages", then you can treat a presence with that feature as as
> good as a XEP-0184: Message Delivery Receipt for all messages that you
> already have a 'stored' notification about.
>
> Similarly, if a "Chat Marker" message implied a promise of retrieval for
> all stored messages before the id in question, we could use that to
> remove the need for XEP-0184-style receipts per message [3].
>
> We probably also need a way to deduplicate Chat
> Markers/receipts/whatever that end up being stored in the archive (in
> many cases, it's only the most recent one that we care about). What
> about:
> ?
>
>
> David.
>
> [1] I will not sleep properly until we have addressed the "End to End
> Acknowledgements" section of:
> http://www.isode.com/whitepapers/reliable-xmpp.html for the "users never
> online at the same time" case
>
> [2] Pretty soon I'm going to end up wit

Re: [Standards] Proposed XMPP Extension: Chat Markers

[Spencer MacDonald]

I would personally be happy with either solution, but if we keep the no
body rule for backwards compatibility, wouldn't we require "positive"
message processing hints too, for when we want to archive a message with no
body? i.e. allow-permanent-storage, allow-storage, allow-copy

Regards

Spencer


On Wed, Jun 19, 2013 at 8:42 PM, Matthew Wild  wrote:

> On 18 June 2013 11:51, Spencer MacDonald
>  wrote:
> > Would it be possible to add "archive indicators" to XEP-0313 to solve my
> > "messages with no body are not archived issue"?.
> >
> > Maybe just adding  as a child of the
> > message?
>
> I've been thinking about this a bit. Since the issue first came up,
> I've been wondering if there are alternatives to the "no-body" rule.
> The problem is that the rule is 95% correct, but when it isn't it's
> not very helpful.
>
> I noted that XEP-0280 (Carbons) has a similar issue, but has an
> explicit flag (the  element) rather than attempting to come
> up with any such rules.
>
> I've written a small proto-XEP that might be able to unify such flags:
> http://matthewwild.co.uk/uploads/message-processing-hints.html
>
> With this we could either remove the no- rule, store by default
> and use no-store. Or we can keep it and add a 'store' hint (this one
> might be easier but feels backwards to me in the grand scheme of
> things).
>
> Thoughts?
>
> Regards,
> Matthew
>

Re: [Standards] Proposed XMPP Extension: Chat Markers

[Spencer MacDonald]

Would it be possible to add "archive indicators" to XEP-0313 to solve my
"messages with no body are not archived issue"?.

Maybe just adding  as a child of the
message?

Spencer


On Thu, Jun 13, 2013 at 4:06 PM, Stephen Paul Weber <
singpol...@singpolyma.net> wrote:

> The stamp is if you read/acknowledge the message while you are offline
>> (assuming you store the messages locally), if it isn't set the time is
>> now.
>>
>
> Oh... isn't that still delayed delivery, though?
>
>
>  The thinking behind chat markers is that people don't deal with individual
>> messages, but with chats. It also has the benefit of if retrieve 100 new
>> messages the next time I log in, I only want to mark up to the last
>> message
>> that I read not send a receipt for every one.
>>
>
> I understand why this seems desirable, and I think for the "displayed"
> status it could work, but for "delivered" this fails to solve the problem
> (at least in my use case, and I'm having a hard time thinking of a use case
> where it's useful) because it *assumes* reliable delivery instead of
> *indicating* it, as 0184 does.
>
> As long as it is used in conjunction with 0184, a "displayed" status of
> "up to" is probably fine.  Though there probably need to be business rules
> about how to deal with threads (such as: do not assume that you can say "up
> to here" if there have been multiple threads.  At least one per thread is
> required.  If a message was received with no thread marker, it must be
> assumed to form a seperate thread.)  In fact, having reasonable business
> logic rules might be enough to differentiate vs just  from 0085
> (which it currently is essentially equivalent to).
>
>
> --
> Stephen Paul Weber, @singpolyma
> See  for how I prefer to be contacted
> edition right joseph
>

Re: [Standards] Proposed XMPP Extension: Chat Markers

[Spencer MacDonald]

Thanks for the feedback,

I will change 'read' to 'displayed' in the next version.

The stamp is if you read/acknowledge the message while you are offline
(assuming you store the messages locally), if it isn't set the time is now.

There is no reason while in addition to this XEP that XEP-0184 couldn't be
extended to also have 'displayed'?

The thinking behind chat markers is that people don't deal with individual
messages, but with chats. It also has the benefit of if retrieve 100 new
messages the next time I log in, I only want to mark up to the last message
that I read not send a receipt for every one.

Regards

Spencer



On Thu, Jun 13, 2013 at 5:02 AM, Stephen Paul Weber <
singpol...@singpolyma.net> wrote:

> The concept of delivery and read receipts has been popularised by other
>> messaging services such as iMessage, Google Hangouts and Blackberry
>> Messenger
>>
>
> The D and R features of BBM are exactly what I am seeking to copy in my
> client.
>
>
>  1.2.1) xep-0022 basically solves this problem, but it is marked as
>> obsolete. I didn't feel like digging it out of the grave, but maybe we
>> should re-consider it?
>>
>
> This summarises my feelings exactly.  I wish 0085 were more like 0022
> (especially wrt the option to omit  notifications, useful on
> mobile).
>
> So, specific comments on chat-markers as written:
>
> The "received" marker is completely useless to me, because it assumes a
> reliable delivery channel.  The entire purpose of the "delivered" state is
> to allow the user to have confidence in the reliability of delivery, so a
> "everything up to here I have" message fails to meet this.  However, no
> problem, because 0184 solves this perfectly (in exactly the same way as
> 0022, but it's not deprecated, so hooray!)
>
> I have no specific comment about "acknowledged".  Not sure how useful that
> is.
>
> So now "read" (more accurately called  by 0022) is the one I
> really need to solve.  Saying "everything up to here has been displayed" is
> probably fine (because I will have delivery recepits from 0184 to tell me
> if they have the message, and if they have it and a later message and they
> say they displayed the later message, then sure I'm fine with assuming
> they're both displayed).  I fail to see, however, how this is different
> from 0085  in that case.  If a chat becomes active and all the
> messages in it have been delivered, then they have now all been displayed.
>  The only disadvantage to 0085 is that  cannot be ommited
> (without SIFT or similar), but I can probably just live with that.
>
> That said, neither 0085 nor chat-markers seems to cover the non-chat
> message case (especially, single/"normal" messages), which likely do not
> fit the "everything up to here" model at all.
>
> Finally, what is up with the stamp="" attribute?  If I was online when the
> stanza was sent, the time is now.  If I was not, then 0203 covers this case
> just fine.  stamp="" seems to be just noise.
>
> For me, I think the ideal protocol would be exactly the same as 0184, but
> with a different namespace that meant  instead of delivered.
>  If a new protocol is even needed.
>
> --
> Stephen Paul Weber, @singpolyma
> See  for how I prefer to be contacted
> edition right joseph
>

Re: [Standards] Proposed XMPP Extension: Chat Markers

[Spencer MacDonald]

I have updated my XEP to be message based (the XML is attached to this
email) and would appreciate any feedback.

As previously mentioned, the only issue now is being able to specify that
chat markers should be archived as they are in a message without a body.

Regards

Spencer



On Wed, Jun 5, 2013 at 10:18 AM, Spencer MacDonald <
spencer.macdonald.ot...@gmail.com> wrote:

> Should I migrate the Chat Marker XEP to a Message based solution and
> assume the issues regarding the storage of the messages with no body will
> be resolved in some way?
>
> Regards
>
> Spencer
>
>
> On Fri, May 31, 2013 at 4:05 PM, David Laban  wrote:
>
>> On Thu, 2013-05-30 at 18:16 +0100, Matthew Wild wrote:
>> > A more general issue is whether this XEP  (or rather the specific
>> > protocol it defines) s necessary at all. I'm not saying it definitely
>> > isn't, but need a little more persuasion. For example it seems that
>> > the primary issue it is working around is that XEP-0136 and XEP-0313
>> > might not save messages with no body. Might it not be easier to solve
>> > this problem instead?
>>
>> Sorry I'm late to the party. I have actually been discussing this with
>> Spencer in the office over the last couple of weeks, so maybe I can give
>> some more motivation for why we feel that an XEP is required. I'm not
>> too attached
>>
>> There are actually a bunch of things that Chat Markers is trying to
>> solve:
>>
>> 1) Atomic "Read Receipt" messages (Or "Seen Receipts" or whatever[1]).
>> 1.1.1) Currently, our pre-alpha implementation of "Seen by $user"
>> markers requires each client to keep track of the state machine
>> (xep-0085) for *each* remote resource. Any incoming 
>> notification, or any incoming  notification from a resource
>> that is in the 'active' state currently updates the "Seen by $user"
>> marker.
>>
>> 1.2.1) xep-0022 basically solves this problem, but it is marked as
>> obsolete. I didn't feel like digging it out of the grave, but maybe we
>> should re-consider it?
>>
>> 1.3.1) I suggested that we could simply include our state (if active) as
>> a sister element to , but Spencer pointed out that xep-0184
>> section 7 states: "When the recipient sends an ack message, it SHOULD
>> ensure that the message stanza contains only one child element". What
>> would break if we did this?
>>
>>
>> 2) State recovery for disconnected clients that come online.
>> 2.1.1) Currently, this is impossible, so our "Seen by $user" marker
>> stays where it is, and messages appear as "Not delivered" when they are
>> retrieved from MAM until a reply is received from the remote party (at
>> which point, we assume that their client has done state recovery from
>> MAM, and mark all messages as received.
>>
>> 2.1.2) xep-0184 section 5.5 Archived Messages states "An entity MUST NOT
>> send an ack message when a user views messages that have been archived
>> or stored on the client or the server (e.g., via Message Archiving [8]),
>> only when first receiving the message."
>>
>> This is annoying, but quite understandable (e.g. what should a client do
>> if it gets  when it doesn't have any knowledge of
>>  or when it might have been sent?)
>>
>> 2.3.1) We could allow MAM to store *all messages*, but then then a query
>> for "how many unread messages to I have since $time" returns a hugely
>> inflated answer. The only way to get an accurate count would then be to
>> retrieve *all messages* and classify them.
>>
>> 2.3.2) We could create a clone of the MAM XEP (let's call it Message
>> State Recovery: MSR) that stores everything without a body, and let the
>> clients query that in order to do state recovery.
>>
>> A little benchmarking of our client's  datastore and a simple
>> thought experiment suggests that this will be many times as large as the
>> MAM database in a naive implementation (when Kate sends a message to
>> Pete, her client will send ; ; (;
>> )* ... and each of Pete's clients will send
>>  and 0 or more will send .
>>
>> Note that we would need to bend the rules for xep-0184 (see 2.1.2) for
>> this to be useful. Specifically (after retrieving all messages from MSR
>> and MAM) for each incoming message in MAM that doesn't have a
>> corresponding outgoing entry in MSR, send a receipt anyway.
>>
>> 2.3.3) We could get the server to store markers for "delivered" and
>> 

Re: [Standards] Proposed XMPP Extension: Chat Markers

[Spencer MacDonald]

Should I migrate the Chat Marker XEP to a Message based solution and assume
the issues regarding the storage of the messages with no body will be
resolved in some way?

Regards

Spencer


On Fri, May 31, 2013 at 4:05 PM, David Laban  wrote:

> On Thu, 2013-05-30 at 18:16 +0100, Matthew Wild wrote:
> > A more general issue is whether this XEP  (or rather the specific
> > protocol it defines) s necessary at all. I'm not saying it definitely
> > isn't, but need a little more persuasion. For example it seems that
> > the primary issue it is working around is that XEP-0136 and XEP-0313
> > might not save messages with no body. Might it not be easier to solve
> > this problem instead?
>
> Sorry I'm late to the party. I have actually been discussing this with
> Spencer in the office over the last couple of weeks, so maybe I can give
> some more motivation for why we feel that an XEP is required. I'm not
> too attached
>
> There are actually a bunch of things that Chat Markers is trying to
> solve:
>
> 1) Atomic "Read Receipt" messages (Or "Seen Receipts" or whatever[1]).
> 1.1.1) Currently, our pre-alpha implementation of "Seen by $user"
> markers requires each client to keep track of the state machine
> (xep-0085) for *each* remote resource. Any incoming 
> notification, or any incoming  notification from a resource
> that is in the 'active' state currently updates the "Seen by $user"
> marker.
>
> 1.2.1) xep-0022 basically solves this problem, but it is marked as
> obsolete. I didn't feel like digging it out of the grave, but maybe we
> should re-consider it?
>
> 1.3.1) I suggested that we could simply include our state (if active) as
> a sister element to , but Spencer pointed out that xep-0184
> section 7 states: "When the recipient sends an ack message, it SHOULD
> ensure that the message stanza contains only one child element". What
> would break if we did this?
>
>
> 2) State recovery for disconnected clients that come online.
> 2.1.1) Currently, this is impossible, so our "Seen by $user" marker
> stays where it is, and messages appear as "Not delivered" when they are
> retrieved from MAM until a reply is received from the remote party (at
> which point, we assume that their client has done state recovery from
> MAM, and mark all messages as received.
>
> 2.1.2) xep-0184 section 5.5 Archived Messages states "An entity MUST NOT
> send an ack message when a user views messages that have been archived
> or stored on the client or the server (e.g., via Message Archiving [8]),
> only when first receiving the message."
>
> This is annoying, but quite understandable (e.g. what should a client do
> if it gets  when it doesn't have any knowledge of
>  or when it might have been sent?)
>
> 2.3.1) We could allow MAM to store *all messages*, but then then a query
> for "how many unread messages to I have since $time" returns a hugely
> inflated answer. The only way to get an accurate count would then be to
> retrieve *all messages* and classify them.
>
> 2.3.2) We could create a clone of the MAM XEP (let's call it Message
> State Recovery: MSR) that stores everything without a body, and let the
> clients query that in order to do state recovery.
>
> A little benchmarking of our client's  datastore and a simple
> thought experiment suggests that this will be many times as large as the
> MAM database in a naive implementation (when Kate sends a message to
> Pete, her client will send ; ; (;
> )* ... and each of Pete's clients will send
>  and 0 or more will send .
>
> Note that we would need to bend the rules for xep-0184 (see 2.1.2) for
> this to be useful. Specifically (after retrieving all messages from MSR
> and MAM) for each incoming message in MAM that doesn't have a
> corresponding outgoing entry in MSR, send a receipt anyway.
>
> 2.3.3) We could get the server to store markers for "delivered" and
> "seen" etc. This is what Chat States attempts to do.
>
>
>
> 3) Efficiency
> 3.1.1) 2.3.2 and 1.1.1 cover a couple of the obvious problems with what
> we have now.
>
> 3.3.1) If we create a MSR XEP, what is the minimum amount of information
> that we can store? If we have solved problem 1) then we can make a lot
> of optimizations. For example, if we used my 1.3.1 proposal, then could
> simply store the last message of each type?
>
> Concretely, could we have a database with the following uniqueness
> constraint:
> (sender_barejid, receiver_barejid, sibling_ns, sibling_name)
>
> where sibling_ns is the namespace of the element after  in
> the  stanza, and sibling_name is its name (e.g. 'active' or
> NULL)?
>
>
> And in reply to Matthew Wild's specific comments:
> >
> > For XEP-0136, it appears to be configurable already in the archiving
> > preferences (surprise surprise!). For XEP-0313, I'm open to discussion
> > about what it recommends.
> >
> We have gone for a Message Archive Management + Message Carbons approach
> so far, which means that clients only need to know how to unpack
> . I don't fancy forcing 3 teams t

Re: [Standards] Proposed XMPP Extension: Chat Markers

[Spencer MacDonald]

>
>
>
> Why? Both sender and receiving server can reuse XEP-0203.
>

When chatting in real time messages dont have the "archive's"
timestamp associated with them.


On Thu, May 30, 2013 at 12:06 PM, Philipp Hancke
wrote:

> Am 29.05.2013 10:40, schrieb Spencer MacDonald:
>
>  IQ vs Message
>>
>> A message based approaches was considered as both chat states and delivery
>> receipts use them, but it had the following disadvantages:
>>
>> - You lose the ability for the server to insert timestamps.
>>
>
> Why? Both sender and receiving server can reuse XEP-0203.
>
>
>  - As mentioned current message archiving solutions don't currently store
>> messages with no body.
>>
>
> Right. And i just had a discussion about that with mattj...
>
> The rationale for that rule was presumably a bad experience when people
> were offline for a long period of time and the amount of  stanzas
> sent by things like rss bots grew over time. IIRC jabberd1 failed to load
> the .xml it used to store things and users could not log in any longer.
>
> Both of us thought that it would serve to avoid storing chat states... but
> those shouldn't go to offline storage in theory anyway (and 0085 has a rule
> about not storing them in the business rules in case they do).
>
> So it might be possible to change that rule, subject to further
> discussion...
>
>
>  - The sender has no way of knowing if an offline entity supports chat
>> markers, so what does the sender do in this situation?
>>
>
> it may send them -- see the business rules in 0184 (bare jid) for an
> example.
>
>
> humm...
>

Re: [Standards] Enabling/Disabling Carbons and Chat Markers

[Spencer MacDonald]

I don't think it needs to know about resources, because like you said
montague.lit
can forward it onto the interested parties.

For MUC the 'room' is in the chat marker so I don't think anything changes
for this.

Spencer


On Wed, May 29, 2013 at 8:00 AM, Lance Stout  wrote:

>
> On May 28, 2013, at 11:18 PM, Kevin Smith  wrote:
>
> > My opinion at the moment is that the current toggle is the sort of
> > protocol wart that it's possible to get caught up in, but really makes
> > no practical difference to anyone beyond aesthetics
>
> I heartily concede that this is very probably the case, especially for
> Carbons; moving on.
>
> > Carbons/Markers are local.
>
> Well, Carbons is local, sure. Markers I'm not sure about yet because
>
> 
>
> the current proposal is still a bit hand wavy when dealing with multiple
> servers. So consider ro...@montague.lit/orchard and 
> jul...@capulet.lit/balcony,
> and both have expressed interest in using chat markers.
>
>
> Romeo sends Juliet a message, and Juliet updates her read information on
> capulet.lit (which is allowed and useful even if Juliet is the only one
> that supports the markers).
>
>
> But capulet.lit needs to know if ro...@montague.lit/orchard supports chat
> markers to send it an updated read marker from Juliet. It would need caps
> for that. Or, does it even care about resources? Does capulet.lit instead
> send a request to the bare ro...@montague.lit to update the marker, and
> let montague.lit archive and forward it to the interested resources? My
> initial feeling is that it should care about resources, because of MUC.

Re: [Standards] Proposed XMPP Extension: Chat Markers

[Spencer MacDonald]

I need what chat markers provides (synchronised delivery and
read receipts across multiple resources) for a project I am currently
working on (hence me proposing it).

>From a previous thread there are already people implementing a custom
version of this in production apps.

Regards

Spencer


On Thu, May 30, 2013 at 8:30 AM, Andreas Kuckartz wrote:

> Are there already projects considering to implement this?
>
> Cheers,
> Andreas
>
>
> XMPP Extensions Editor:
> > The XMPP Extensions Editor has received a proposal for a new XEP.
> >
> > Title: Chat Markers
> >
> > Abstract: This specification describes a solution of marking the last
> received, read and acknowledged message in a chat.
> >
> > URL: http://xmpp.org/extensions/inbox/chat-markers.html
> >
> > The XMPP Council will decide in the next two weeks whether to accept
> this proposal as an official XEP.
>

Re: [Standards] Proposed XMPP Extension: Chat Markers

[Spencer MacDonald]

Enable/Disable vs Subscribe/Unsubscribe

I did originally have the element named "enable" instead of "subscribe",
but I felt it read like you were enabling/disabling chat markers
entirely rather than them just enabling/disabling them being automatically
pushed to you.

As mentioned in another thread, an alternative approach would be to
automatically send your chat markers if you advertise support which negates
this step.

IQ vs Message

A message based approaches was considered as both chat states and delivery
receipts use them, but it had the following disadvantages:

- You lose the ability for the server to insert timestamps.
- As mentioned current message archiving solutions don't currently store
messages with no body.
- The sender has no way of knowing if an offline entity supports chat
markers, so what does the sender do in this situation?

Regards

Spencer


On Wed, May 29, 2013 at 6:53 AM, Philipp Hancke
wrote:

> Am 28.05.2013 22:44, schrieb XMPP Extensions Editor:
>
>  The XMPP Extensions Editor has received a proposal for a new XEP.
>>
>> Title: Chat Markers
>>
>> Abstract: This specification describes a solution of marking the last
>> received, read and acknowledged message in a chat.
>>
>> URL: 
>> http://xmpp.org/extensions/**inbox/chat-markers.html
>>
>
> quick glance:
>
> section 2:
> The term "active chat" refers to a chat that a user is currently active in.
> -- doesn't 0085 have a definition of that?
>
> section 4:
> read -- the message the user has viewed it in a active chat.
> s/the message//
>
> displayed -- the message has been displayed to the user in an
>  active chat
> would be easier to define than "the user has viewed it"
>
>
> section 6.1:
> can this be more aligned with what we have in carbons? E.g.
> type='set'
>id='enable1'>
>  
> 
>
>
> Design-wise I'd prefer  to . But I think the rule not to
> store bodyless messages is wrong and therefore ignore that. The offline
> use-case is important however.
>
>  in combination with carbons might fulfill the multi-client
> usecase better.
>
>

Re: [Standards] ProtoXEP offered; google:queue

[Spencer MacDonald]

For sure, just thought I would put the Facebook implementation out there :)

Regards

Spencer


On Thu, May 23, 2013 at 10:40 AM, Dave Cridland  wrote:

>
> On 23 May 2013 10:29, "Spencer MacDonald" <
> spencer.macdonald.ot...@gmail.com> wrote:
> >
> > In all seriousness if this was to be forked into a XEP, it should have a
> few more configuration options.
> >
> > Facebook also have an undocumented feature called suspend
> https://bugs.freedesktop.org/show_bug.cgi?id=38943
> >
> > Facebook's implementation is more desirable on platforms such as iOS, as
> if you are "suspended" you don't which to receive anything.
> >
> I think that we need to document what we have as best we can, and design
> something properly once we have everything on the table.
>
> Dave.
>

Re: [Standards] ProtoXEP offered; google:queue

[Spencer MacDonald]

In all seriousness if this was to be forked into a XEP, it should have a
few more configuration options.

Facebook also have an undocumented feature called suspend
https://bugs.freedesktop.org/show_bug.cgi?id=38943

Facebook's implementation is more desirable on platforms such as iOS, as if
you are "suspended" you don't which to receive anything.

Regards

Spencer



On Thu, May 23, 2013 at 8:55 AM, Dave Cridland  wrote:

> The timing's now reached the perfect level of irony, I think.
>
> Dave.
>

Re: [Standards] Forward Stanza Inconsistency between XEP-0280 and XEP-0313

[Spencer MacDonald]

Thanks Lance,

OK so the xmlns element should be a parent not a sibling. 

Regards

Spencer


On Wednesday, 22 May 2013 at 20:37, Lance Stout wrote:

> On May 22, 2013, at 12:27 PM, Spencer MacDonald 
>  wrote:
> 
> > Hi,
> > 
> > Maybe there is a good reason for it, but in XEP-0280 Message Carbons the 
> > forwarded stanza is nested in either a received or sent element with the 
> > carbons xmlns.
> > 
> > In XEP-0313 Message Archive Management the result element with the mam 
> > xmlns is a sibling of the forwarded stanza.
> > 
> > Should there be a standard for this in terms of wether the xmlns element 
> > should be the parent or sibling of the forwarded stanza?
> 
> This is just because MAM hasn't been updated to match yet. See 
> http://matthewwild.co.uk/uploads/xep-0313.html
> 
> 
> -- Lance 

[Standards] Forward Stanza Inconsistency between XEP-0280 and XEP-0313

[Spencer MacDonald]

Hi, 

Maybe there is a good reason for it, but in XEP-0280 Message Carbons the 
forwarded stanza is nested in either a received or sent element with the 
carbons xmlns.

In XEP-0313 Message Archive Management the result element with the mam xmlns is 
a sibling of the forwarded stanza.

Should there be a standard for this in terms of wether the xmlns element should 
be the parent or sibling of the forwarded stanza?


Regards

Spencer

Re: [Standards] XEP-0313 Message Archive Management Message Removal

[Spencer MacDonald]

The only issue I can foresee with this approach is if you have 3 messages,
"Initial Message", "Corrected Message" and "Other Message", you could
potential only fetch "Initial Message" and "Other Message" and the client
would not know that "Initial Message" had been subsequently corrected.

Maybe this isn't such a big deal but it could happen?

As I side note, wouldn't it make more sense if XEP-0308 was just called
"Message Correction" rather than "Last Message Correction"?

Regards

Spencer


On Sat, May 18, 2013 at 7:23 PM, Matthew Wild  wrote:

> On 18 May 2013 14:33, Kim Alvefur  wrote:
> > On Sat, 18 May 2013, 14:23:43 CEST, Spencer MacDonald <
> spencer.macdonald.ot...@gmail.com> wrote:
> >> Also you may say something that is "confidential" that you might want to
> >> remove after the recipient has acknowledged it.
> >
> > You really want to use some end-to-end encryption for that.
> >
> > Carbons (XEP-280) has a method for excluding single messages from
> processing.  That could be used to signal a wish for having a message
> excluded from archiving, possibly broken out into a XEP of its own.
>
> +1, I like that approach (partly because it doesn't necessarily need
> adding to XEP-0313, yay!). XEP-0136's controls for this were quite
> complicated, but a simple tag that disables carbons, archiving and
> perhaps other kinds of server processing would be quite welcome.
>
> > Or maybe security-labels.
>
> Now you go and ruin it... :)
>
> Regards,
> Matthew
>

Re: [Standards] XEP-0313 Message Archive Management Message Removal

[Spencer MacDonald]

No problem, I can understand your concerns as XEP-0136 is very bloated and
complicated.

Simply if you say something that is incorrect or in the wrong chat then you
will want to delete it.

Also you may say something that is "confidential" that you might want to
remove after the recipient has acknowledged it.

XEP-0308: Last Message Correction, kind of deals with these issues but
unless you fetch your entire archive you might not get the corrections for
previous messages.

Maybe the solution isn't Message Removal, but rather better integration
between these 2 XEPs.

Regards

Spencer


On Sat, May 18, 2013 at 12:46 PM, Matthew Wild  wrote:

> Hi,
>
> On 17 May 2013 20:49, Spencer MacDonald
>  wrote:
> > One of the features from XEP-0136 that I would like to see included in
> > XEP-0313 is message removal.
>
> > Would it be possible to include this?
>
> Without saying yes or no... I'll just ask, what's the actual use case?
>
> I am really keen to prevent feature creep in this specification. After
> all, pretty much everything in XEP-0136 was wanted by somebody at some
> point. If we similarly include everything everyone asks for then the
> new specification will end up a pointless exercise - we'll just end up
> with XEP-0136 under a new namespace.
>
> Regards,
> Matthew
>

[Standards] XEP-0313 Message Archive Management Message Removal

[Spencer MacDonald]

One of the features from XEP-0136 that I would like to see included in
XEP-0313 is message removal.

It could follow the same logic as message retrieval, just instead of
"query" it would be "remove" and be of type "set":




jul...@capulet.com
2010-06-07T00:00:00Z
2010-07-07T13:23:54Z



Would it be possible to include this?

Regards

Spencer

[Standards] XEP-0313 Message Archive Management example inconsistency

[Spencer MacDonald]

Hi,

I think in example 5 http://xmpp.org/extensions/xep-0059.html#limit, the
Result Set should use max and not limit.

*Example 5. A query using Result Set Management*



  

  2010-08-07T00:00:00Z

  

 10

  

  





XEP 0059 Results Set Management doesn't specify the limit tag and according
to the spec max would achieve exactly the same thing.

Regards

Spencer