Re: [Standards] XEP-0313 / XEP-0359 interaction

[Florian Schmaus]

On 25.03.19 22:07, Dave Cridland wrote:
> On Mon, 25 Mar 2019 at 14:03, Florian Schmaus  > wrote:
> On 25.03.19 13:52, Dave Cridland wrote:
> > On Mon, 25 Mar 2019 at 12:26, Florian Schmaus  
> > >> wrote:
> >     I lean towards 2. Which could mean that
> >
> >      >     to='u...@example.com 
> >'>
> >       
> >     
> >
> >     does not indicate archival of the message into
> u...@example.com 
> >     >'s MAM
> >     archive, while
> >
> >      >     to='u...@example.com 
> >'>
> >       
> >     
> >
> >     does.
> >
> >
> > Ah, so the first suggests the message is archived by the server-level
> > archive?
> 
> I'd say it depends whether "example.com "
> announces the MAM disco#info
> feature. And I also believe that this does not automatically imply for
> the receiving entity that it has access to that message in the archive
> (if there is one).
> 
> 
> Ah, so the semantics of XEP-0359 vary depending on an unrelated
> specification not referenced by the document in ways that are not
> specified in either document?

I wouldn't say that the semantics of XEP-0359 vary. The 
element tells you that an entity, identified by the JID in the 'by'
value, assigned a particular ID to this stanza. If and how you could
potentially lookup the stanza depends on various factors, including that
you and the entity need to speak a common protocol. As you possibly know
we usually use disco#info to determine the available features and
supported protocols of an entity, hence a lookup only appears obvious to
me. I am happy to clarify that in case the idea isn't as obvious as I
thought it to be.

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0313 / XEP-0359 interaction

[Dave Cridland]

On Mon, 25 Mar 2019 at 14:03, Florian Schmaus  wrote:

> On 25.03.19 13:52, Dave Cridland wrote:
> >
> >
> > On Mon, 25 Mar 2019 at 12:26, Florian Schmaus  > > wrote:
> >
> > On 25.03.19 12:48, Guus der Kinderen wrote:
> > > XEP-0313 "Message Archive Management" (v0.6.3) relies on XEP-0359
> > > "Unique and Stable Stanza IDs" to identify content in the archive.
> > >
> > > MAM provides an archive on the server, which can be efficiently
> > > synchronized with a client-sided archive. It does this using the
> IDs
> > > from XEP-0359. It's a simple query: the client provides an ID of a
> > > message in the archive, the server responds with all later
> messages.
> > >
> > > Although this is a simple, elegant solution, it breaks when the
> client
> > > receives messages that have XEP-0359 IDs, but are not part of the
> > > (server-sided) archive. This puts quite a restrication on XEP-0359
> use
> > > in other contexts than MAM. Can this be improved upon?
> >
> > I think some more context could be helpful. As far as I know this
> come
> > up yesterday (?) in the xsf@ MUC in a discussion between Guus and
> MattJ
> > (and waqas).
> >
> > As far as I understood it, prior MAM versions used an 
> > element which not only contains the ID of the message stanza in the
> > archive but also carries the semantic that the message was actually
> > archived.
> >
> > Now Guus wants for some reason to slap a  on every
> message,
> > irregardless if it was archived or not. MattJ argued that this would
> > break client's assumption that messages with a  are
> actually
> > archived. This assumes that clients simply remember the last
> stanza-id
> > of the message they received and perform a resync of the archive when
> > they come online again.
> >
> > Keep in mind that MAM archives may not archive every message stanza,
> > think of IBB messages and the like.
> >
> > I do not claim to understand every statement and argument in this
> > discussion, so please correct me if I am wrong. I am also not sure if
> > the problem is an actual problem: There was a interesting discussion
> > between MattJ and waqas regarding the guarantees client developers
> can
> > expect from a MAM archive.
> >
> > But what I understood is when XEP-MAM switched from  to
> >  there possibly, depending on the guarantees you expect
> from
> > MAM, was a loss of semantic.
> >
> > I see multiple potential solutions:
> >
> > 1. Introduce an archived flag
> > 2. Use 's 'by' attribute to carry the archived or not
> > semantic
> > 3. Potential others
> >
> > I lean towards 2. Which could mean that
> >
> >  > to='u...@example.com '>
> >   
> > 
> >
> > does not indicate archival of the message into u...@example.com
> > 's MAM
> > archive, while
> >
> >  > to='u...@example.com '>
> >   
> > 
> >
> > does.
> >
> >
> > Ah, so the first suggests the message is archived by the server-level
> > archive?
>
> I'd say it depends whether "example.com" announces the MAM disco#info
> feature. And I also believe that this does not automatically imply for
> the receiving entity that it has access to that message in the archive
> (if there is one).
>
>
Ah, so the semantics of XEP-0359 vary depending on an unrelated
specification not referenced by the document in ways that are not specified
in either document?

Glad that's clear then. :-)


> - Florian
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0313 / XEP-0359 interaction

[Florian Schmaus]

On 25.03.19 13:52, Dave Cridland wrote:
> 
> 
> On Mon, 25 Mar 2019 at 12:26, Florian Schmaus  > wrote:
> 
> On 25.03.19 12:48, Guus der Kinderen wrote:
> > XEP-0313 "Message Archive Management" (v0.6.3) relies on XEP-0359
> > "Unique and Stable Stanza IDs" to identify content in the archive.
> >
> > MAM provides an archive on the server, which can be efficiently
> > synchronized with a client-sided archive. It does this using the IDs
> > from XEP-0359. It's a simple query: the client provides an ID of a
> > message in the archive, the server responds with all later messages.
> >
> > Although this is a simple, elegant solution, it breaks when the client
> > receives messages that have XEP-0359 IDs, but are not part of the
> > (server-sided) archive. This puts quite a restrication on XEP-0359 use
> > in other contexts than MAM. Can this be improved upon?
> 
> I think some more context could be helpful. As far as I know this come
> up yesterday (?) in the xsf@ MUC in a discussion between Guus and MattJ
> (and waqas).
> 
> As far as I understood it, prior MAM versions used an 
> element which not only contains the ID of the message stanza in the
> archive but also carries the semantic that the message was actually
> archived.
> 
> Now Guus wants for some reason to slap a  on every message,
> irregardless if it was archived or not. MattJ argued that this would
> break client's assumption that messages with a  are actually
> archived. This assumes that clients simply remember the last stanza-id
> of the message they received and perform a resync of the archive when
> they come online again.
> 
> Keep in mind that MAM archives may not archive every message stanza,
> think of IBB messages and the like.
> 
> I do not claim to understand every statement and argument in this
> discussion, so please correct me if I am wrong. I am also not sure if
> the problem is an actual problem: There was a interesting discussion
> between MattJ and waqas regarding the guarantees client developers can
> expect from a MAM archive.
> 
> But what I understood is when XEP-MAM switched from  to
>  there possibly, depending on the guarantees you expect from
> MAM, was a loss of semantic.
> 
> I see multiple potential solutions:
> 
> 1. Introduce an archived flag
> 2. Use 's 'by' attribute to carry the archived or not
> semantic
> 3. Potential others
> 
> I lean towards 2. Which could mean that
> 
>  to='u...@example.com '>
>   
> 
> 
> does not indicate archival of the message into u...@example.com
> 's MAM
> archive, while
> 
>  to='u...@example.com '>
>   
> 
> 
> does.
> 
> 
> Ah, so the first suggests the message is archived by the server-level
> archive?

I'd say it depends whether "example.com" announces the MAM disco#info
feature. And I also believe that this does not automatically imply for
the receiving entity that it has access to that message in the archive
(if there is one).

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0313 / XEP-0359 interaction

[Ненахов Андрей]

We actually use 313/359 to control message delivery from client to local
and remote servers. It's a cornerstone of all our protocol extensions.

пн, 25 мар. 2019 г. в 17:54, Dave Cridland :

>
>
> On Mon, 25 Mar 2019 at 12:26, Florian Schmaus  wrote:
>
>> On 25.03.19 12:48, Guus der Kinderen wrote:
>> > XEP-0313 "Message Archive Management" (v0.6.3) relies on XEP-0359
>> > "Unique and Stable Stanza IDs" to identify content in the archive.
>> >
>> > MAM provides an archive on the server, which can be efficiently
>> > synchronized with a client-sided archive. It does this using the IDs
>> > from XEP-0359. It's a simple query: the client provides an ID of a
>> > message in the archive, the server responds with all later messages.
>> >
>> > Although this is a simple, elegant solution, it breaks when the client
>> > receives messages that have XEP-0359 IDs, but are not part of the
>> > (server-sided) archive. This puts quite a restrication on XEP-0359 use
>> > in other contexts than MAM. Can this be improved upon?
>>
>> I think some more context could be helpful. As far as I know this come
>> up yesterday (?) in the xsf@ MUC in a discussion between Guus and MattJ
>> (and waqas).
>>
>> As far as I understood it, prior MAM versions used an 
>> element which not only contains the ID of the message stanza in the
>> archive but also carries the semantic that the message was actually
>> archived.
>>
>> Now Guus wants for some reason to slap a  on every message,
>> irregardless if it was archived or not. MattJ argued that this would
>> break client's assumption that messages with a  are actually
>> archived. This assumes that clients simply remember the last stanza-id
>> of the message they received and perform a resync of the archive when
>> they come online again.
>>
>> Keep in mind that MAM archives may not archive every message stanza,
>> think of IBB messages and the like.
>>
>> I do not claim to understand every statement and argument in this
>> discussion, so please correct me if I am wrong. I am also not sure if
>> the problem is an actual problem: There was a interesting discussion
>> between MattJ and waqas regarding the guarantees client developers can
>> expect from a MAM archive.
>>
>> But what I understood is when XEP-MAM switched from  to
>>  there possibly, depending on the guarantees you expect from
>> MAM, was a loss of semantic.
>>
>> I see multiple potential solutions:
>>
>> 1. Introduce an archived flag
>> 2. Use 's 'by' attribute to carry the archived or not semantic
>> 3. Potential others
>>
>> I lean towards 2. Which could mean that
>>
>> 
>>   
>> 
>>
>> does not indicate archival of the message into u...@example.com's MAM
>> archive, while
>>
>> 
>>   
>> 
>>
>> does.
>>
>>
> Ah, so the first suggests the message is archived by the server-level
> archive?
>
>
>> - Florian
>>
>> ___
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: standards-unsubscr...@xmpp.org
>> ___
>>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>


-- 
Andrew Nenakhov
CEO, Redsolution, Inc.
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0313 / XEP-0359 interaction

[Dave Cridland]

On Mon, 25 Mar 2019 at 12:26, Florian Schmaus  wrote:

> On 25.03.19 12:48, Guus der Kinderen wrote:
> > XEP-0313 "Message Archive Management" (v0.6.3) relies on XEP-0359
> > "Unique and Stable Stanza IDs" to identify content in the archive.
> >
> > MAM provides an archive on the server, which can be efficiently
> > synchronized with a client-sided archive. It does this using the IDs
> > from XEP-0359. It's a simple query: the client provides an ID of a
> > message in the archive, the server responds with all later messages.
> >
> > Although this is a simple, elegant solution, it breaks when the client
> > receives messages that have XEP-0359 IDs, but are not part of the
> > (server-sided) archive. This puts quite a restrication on XEP-0359 use
> > in other contexts than MAM. Can this be improved upon?
>
> I think some more context could be helpful. As far as I know this come
> up yesterday (?) in the xsf@ MUC in a discussion between Guus and MattJ
> (and waqas).
>
> As far as I understood it, prior MAM versions used an 
> element which not only contains the ID of the message stanza in the
> archive but also carries the semantic that the message was actually
> archived.
>
> Now Guus wants for some reason to slap a  on every message,
> irregardless if it was archived or not. MattJ argued that this would
> break client's assumption that messages with a  are actually
> archived. This assumes that clients simply remember the last stanza-id
> of the message they received and perform a resync of the archive when
> they come online again.
>
> Keep in mind that MAM archives may not archive every message stanza,
> think of IBB messages and the like.
>
> I do not claim to understand every statement and argument in this
> discussion, so please correct me if I am wrong. I am also not sure if
> the problem is an actual problem: There was a interesting discussion
> between MattJ and waqas regarding the guarantees client developers can
> expect from a MAM archive.
>
> But what I understood is when XEP-MAM switched from  to
>  there possibly, depending on the guarantees you expect from
> MAM, was a loss of semantic.
>
> I see multiple potential solutions:
>
> 1. Introduce an archived flag
> 2. Use 's 'by' attribute to carry the archived or not semantic
> 3. Potential others
>
> I lean towards 2. Which could mean that
>
> 
>   
> 
>
> does not indicate archival of the message into u...@example.com's MAM
> archive, while
>
> 
>   
> 
>
> does.
>
>
Ah, so the first suggests the message is archived by the server-level
archive?


> - Florian
>
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0313 / XEP-0359 interaction

[Philipp Hörist]

Hi,

There is no loss in semantic, the XEP states

>  The 'by' attribute MUST be set to the address of the archive.

so its clear to every client developer at any point in time, what message
was archived by the server, and on what message some user or server just
added another  element.

Further 0359 states

> Stanza ID generating entities, which encounter a  element
where the 'by' attribute matches the 'by' attribute they would otherwise
set, MUST delete that element even if they are not adding their own stanza
ID.

So i would say this is as save as it gets, and only misbehaving clients or
server will have problems.

Regards
Philipp
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0313 / XEP-0359 interaction

[Holger Weiß]

* Guus der Kinderen  [2019-03-25 12:48]:
> Although this is a simple, elegant solution, it breaks when the client
> receives messages that have XEP-0359 IDs, but are not part of the
> (server-sided) archive.

As far as I can see, it doesn't break as long as the server is aware of
the ordering of the non-archived messages compared to the archived ones.
(But I can easily see how this awareness can be hard/ugly to implement,
so yes I see your point.)

Holger
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0313 / XEP-0359 interaction

[Florian Schmaus]

On 25.03.19 12:48, Guus der Kinderen wrote:
> XEP-0313 "Message Archive Management" (v0.6.3) relies on XEP-0359
> "Unique and Stable Stanza IDs" to identify content in the archive.
> 
> MAM provides an archive on the server, which can be efficiently
> synchronized with a client-sided archive. It does this using the IDs
> from XEP-0359. It's a simple query: the client provides an ID of a
> message in the archive, the server responds with all later messages.
> 
> Although this is a simple, elegant solution, it breaks when the client
> receives messages that have XEP-0359 IDs, but are not part of the
> (server-sided) archive. This puts quite a restrication on XEP-0359 use
> in other contexts than MAM. Can this be improved upon?

I think some more context could be helpful. As far as I know this come
up yesterday (?) in the xsf@ MUC in a discussion between Guus and MattJ
(and waqas).

As far as I understood it, prior MAM versions used an 
element which not only contains the ID of the message stanza in the
archive but also carries the semantic that the message was actually
archived.

Now Guus wants for some reason to slap a  on every message,
irregardless if it was archived or not. MattJ argued that this would
break client's assumption that messages with a  are actually
archived. This assumes that clients simply remember the last stanza-id
of the message they received and perform a resync of the archive when
they come online again.

Keep in mind that MAM archives may not archive every message stanza,
think of IBB messages and the like.

I do not claim to understand every statement and argument in this
discussion, so please correct me if I am wrong. I am also not sure if
the problem is an actual problem: There was a interesting discussion
between MattJ and waqas regarding the guarantees client developers can
expect from a MAM archive.

But what I understood is when XEP-MAM switched from  to
 there possibly, depending on the guarantees you expect from
MAM, was a loss of semantic.

I see multiple potential solutions:

1. Introduce an archived flag
2. Use 's 'by' attribute to carry the archived or not semantic
3. Potential others

I lean towards 2. Which could mean that


  


does not indicate archival of the message into u...@example.com's MAM
archive, while


  


does.

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0313 / XEP-0359 interaction

[Kevin Smith]

On 25 Mar 2019, at 11:48, Guus der Kinderen  wrote:
> 
> XEP-0313 "Message Archive Management" (v0.6.3) relies on XEP-0359 "Unique and 
> Stable Stanza IDs" to identify content in the archive.
> 
> MAM provides an archive on the server, which can be efficiently synchronized 
> with a client-sided archive. It does this using the IDs from XEP-0359. It's a 
> simple query: the client provides an ID of a message in the archive, the 
> server responds with all later messages.
> 
> Although this is a simple, elegant solution, it breaks when the client 
> receives messages that have XEP-0359 IDs, but are not part of the 
> (server-sided) archive. This puts quite a restrication on XEP-0359 use in 
> other contexts than MAM. Can this be improved upon?

I think that as long as it doesn’t stamp on the user’s archive, it won’t 
interact with MAM will it?

/K

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0313 / XEP-0359 interaction

[Guus der Kinderen]

XEP-0313 "Message Archive Management" (v0.6.3) relies on XEP-0359 "Unique
and Stable Stanza IDs" to identify content in the archive.

MAM provides an archive on the server, which can be efficiently
synchronized with a client-sided archive. It does this using the IDs from
XEP-0359. It's a simple query: the client provides an ID of a message in
the archive, the server responds with all later messages.

Although this is a simple, elegant solution, it breaks when the client
receives messages that have XEP-0359 IDs, but are not part of the
(server-sided) archive. This puts quite a restrication on XEP-0359 use in
other contexts than MAM. Can this be improved upon?

  - Guus
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Council Voting Summary 2019-03-17

[Dave Cridland]

On Sat, 23 Mar 2019 at 09:14, Evgeny  wrote:

> Hey, Georg, Dave.
>
> I think I have addressed all your concerns in my new local copy [1]
>
> [1] http://upload.zinid.ru/xep-eax-cir.html
>
>
Thanks, but for the avoidance of doubt, I had no concerns that needed to be
addressed prior to adoption.


> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___