[Standards] The Open Graph protocol

[Severino Ferrer de la Peñita]

Hello!
I'm working on a Prosody module that will use XEP-0422: Message Fastening ( 
https://xmpp.org/extensions/xep-0422.html )
to attach URL previews to messages by fetching Open Graph Protocol  
elements from the URL pasted in the chat.
I would like to settle on a format that makes sense for XMPP so clients could 
easily understand these fastenings if they wanted to.

My ideal scenario would be to basically send the same elements as the ones 
described in https://opengraphprotocol.org/
so as a client developer one would have https://opengraphprotocol.org/ as the 
one and only source of truth and avoid
having some kind of translator between OGP and the XMPP format.

Using the example from https://opengraphprotocol.org/ a quick prototype could 
be something like:


1)












This would be my current preferred way to go, so as a client developer, 
whenever I wanted to extend my client,
I would go to the OGP specification and include any new properties available.

The problem I see is possibly with the values of the property attribute. One 
could say the 'og:' prefix is redundant
or that it doesn't look "xmppish" to have an attribute value like 'og:title'

Maybe, would this make more sense if that's the issue?

2)



IMDb
video.movie
The Rock (1996) - IMDb
http://www.imdb.com/title/tt0117500/http://www.imdb.com/title/tt0117500/ >
Directed by Michael Bay. With Sean Connery, Nicolas 
Cage, Ed Harris, John Spencer...
https://m.media...jpghttps://m.media...jpg >




After scrolling down a bit, I stumbled upon some properties having related 
content in this form (notice the value of the property attribute):


Then, should the format be something like this?

3)



IMDb
video.movie
The Rock (1996) - IMDb
http://www.imdb.com/title/tt0117500/http://www.imdb.com/title/tt0117500/ >
Directed by Michael Bay. With Sean Connery, Nicolas Cage, Ed 
Harris, John Spencer...

400
300
A shiny red apple with a bite taken out
https://secure.example.com/ogp.jpghttps://secure.example.com/ogp.jpg >
image/jpeg





My initial thought is to stick with the first example I've mentioned and do 
something like:

// Stuff I support for my previews
PREVIEW = {
IMAGE = 'og:image',
DESCRIPTION = 'og:description',
TITLE = 'og:title',
}
.
.
.
apply_to = message.children(xmlns='urn:xmpp:fasten:0')
preview = Preview.new(to=apply_to.id)

for meta in apply_to.children()
switch(meta.property)
case PREVIEW.IMAGE:
preview.image = meta.content
case PREVIEW.DESCRIPTION:
preview.description = meta.content
case PREVIEW.TITLE:
preview.title = meta.content

preview.display()

What do you think? Has anyone already implemented such format or feature?
I would appreciate any feedback and suggestions, thank you! :)

PS: I know, I know. You are right, this is a client feature and all this is not 
needed, but it is useful in scenarios where as an operator
I want to avoid clients automatically visiting URLs without voluntary action, 
for example.


Kind regards,

Seve
https://delape.net
https://github.com/SeveFP
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Pre-Authenticated In-Band Registration

[Sam Whited]

I missed this statement about 0389 last time. This is incorrect, 0389
does not use stanzas pre-auth, it just has the ability to use stanzas to
do the same thing post-auth because I wanted to be able to register with
something other than the server. For example, you might want an admin
console that exists post-auth if you're an admin that lets you register
accounts on a MUC component (which requires stanzas to be routable).
The IQs are not to be used pre-auth.

I will clarify this in the XEP; sorry for the confusion.

—Sam

On Wed, Nov 4, 2020, at 03:09, Georg Lukas wrote:
> Well, I'm not an expert on authentication and registration mechanisms,
> and I didn't want to become one just for solving an urgent practical
> problem, but it looks like there is XEP-0389: Extensible In-Band
> Registration, which *also* relies on unauthenticated IQs, that can be
> moved into the right direction in the long term, and also some ongoing
> work around SASL2.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0443 (XMPP Compliance Suites 2021)

[Martin Dosch]

Dear all,

I would like to also have XEP-0425: Message Moderation [1] added to the 
XMPP Compliance Suites 2021 as spam messages to MUCs are happening more 
often.


Would you consider adding it to advanced client and advanced server?

Best regards,
Martin

[1] https://xmpp.org/extensions/xep-0425.html


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

Re: [Standards] Use of XEP-0198 resumption under adverse network conditions

[Ruslan N. Marchenko]

Am Mittwoch, den 04.11.2020, 11:46 + schrieb Dave Cridland:
> 
> Due to network analysis (and "thanks" to a bug in the server which
> caused some useful logging), we were able to examine not only when
> sessions went into the unresponsive state, but also when the client
> subsequently sent traffic on that session. This often happened well
> after the session had fallen into the resumable state - this resulted
> in an error, as the session had been closed.
> 
> Having seen the result of this in the logging of the server, we
> followed up by looking for the same logging output on the production
> system, where the majority of users are using WiFi or 4G within
> hospitals. Coverage is often poor, and the WiFi overused, so
> clinicians often operate on a weak 4G signal, or highly contented
> WiFi. Think FOSDEM.
> 
> Again, we observed clients recovering sometimes well after the ping
> timeout had triggered. Had these clients been able to, they could
> have continued to use the same TCP session without any disruption
> (or, for that matter, any additional RTTs re-establishing).
> 
> The usual approach here seems to be to increase the timeout required
> to move a session from "live" to "unresponsive" when pinged. However,
> this has the effect of delaying push notifications while the session
> is, in effect in limbo.
> 
> Our proposal is that when a session is found to be unresponsive, the
> server starts sending push notifications for unacknowledged (and
> future) messages, but otherwise leaves the session live when
> resumable. Only after a significantly longer timeout should the TCP
> session be terminated (and at that point destroy the session
> entirely).
> 

Matches my observations [1] as well. If the session is not too active
tcp recovery is instant, all the snd/rcv buffers are flushed and then
queues are flushed and all live as if nothing happened. 

> This means that a client recovering network after several minutes
> will find the connection still live (in effect), whereas if it never
> recovers, it will still get the push notifications in a timely
> manner.
> 
> There are likely to be downsides with this approach; particularly
> presence state will be badly affected. PSA could help here. Overall,
> though, we believe that this will substantially improve the effective
> performance of C2S over high latency, high contention links.

I'm leaning towards ignoring all the timers whatsoever, only care about
how it affects UX. If tcp is still holding up - let it be, if it got
EOF/EOS/Timeout (from whatever side) - let's just do resumption
reconnection - we're reconnectiong continuously anyway.

1. -
 https://github.com/TelepathyIM/wocky/issues/14#issuecomment-720091807
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Pre-Authenticated In-Band Registration

[Sam Whited]

TL;DR IMO we should be stricter about the sync/async separation and not
add more IQs before the session is established.

I'd like to second this, but not from a security perspective but from a
general dev / separation of concerns prospective (which I suppose is
also a security perspective). An XMPP session in general can be divided
up into the synchronous session establishment and the async session that
you establish. IQs are meant to be used in the async part and their
semantics only make sense in an async context (eg. they have IDs used to
track responses, but this is not needed if the response will always be
the next thing received). With the exception of the resource binding IQ,
this distinction holds and I normally write my code to assume this
distinction, then have to find a way to piggy back IQ semantics (which I
had written tied into async code requiring a session) onto the binding
IQ. This normally means duplicate logic and more places in the code for
bugs when the parts I had to rewrite (mirroring an ID and the like)
aren't even necessary.

—Sam

On Tue, Nov 3, 2020, at 16:51, Dave Cridland wrote:
> My main concern here is the addition of a further IQ during
> unauthenticated state. In the case of every server I've worked with,
> the IBR (and '78 auth, if supported) is hard-coded into the server.
> This generally feels like a security nightmare lurking.
>
> I would rather move in the other direction, and place the entirety of
> registration inside non-stanza TLEs or (possibly) opting for a registration-
> only authentication before exchanging stanzas.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Use of XEP-0198 resumption under adverse network conditions

[Marvin W]

Hi Dave,

Thanks for your message. From my experience with mobile phone networks
when traveling in Germany (not sure if it applies in other countries, as
German mobile networks are far below average in my experience), I can
confirm that temporary connectivity loss is not handled perfectly well
in some scenarios (although I am not sure if this is a server or client
side issue).

On 04.11.20 12:46, Dave Cridland wrote:
> Our proposal is that when a session is found to be unresponsive, the
> server starts sending push notifications for unacknowledged (and
> future) messages, but otherwise leaves the session live when
> resumable. Only after a significantly longer timeout should the TCP
> session be terminated (and at that point destroy the session
> entirely).

FWIW, this is within the bounds of the current specification. XEP-0357
leaves it completely open which events warrant a push notification.

The prosody mod_cloud_notify already is supposed to send push
notifications when the session is still considered "live", but the
outgoing message was not ack-ed using XEP-0198 for a certain time (can
be configured). When using this together with an increased connection
timeout (which is configurable in prosody's advanced network
configuration as per ) you should
be able to realize something that is pretty close to your suggestion.

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

Re: [Standards] Use of XEP-0198 resumption under adverse network conditions

[Guus der Kinderen]

Hi Dave,

Thanks for sharing this. To verify that I got it wrong, can I dumb your
suggestions down by summarizing them as:

   - Increase the timeout after which a connection is considered
   unrecoverably dead (to ... how many minutes?)
   - After a period of inactivity that's a lot shorter than the timeout
   mentioned above (presumable around the existing timeout value) start
   generating push notifications

Regards,

  Guus

On Wed, 4 Nov 2020 at 12:48, Dave Cridland  wrote:

> Hey all,
>
> We (that is, myself and others from Forward Clinical Ltd, my employer)
> have been doing some extensive work to support high latency networks such
> as Satellite Links, in relation to our work with UK Defence Medical
> Services. Our "long thin" links cover the C2S link.
>
> We believe these findings are more generally useful than just SATCOM - in
> particular, we think these will help with the adverse network conditions
> found in hospitals (where people keep putting in lifts and lots of cables,
> giving lots of blackspots), and general applicability with mobile use of
> XMPP.
>
> TL;DR: When the session has a ping timeout, do push notifications, but
> otherwise leave it open - mobile clients will often recover after several
> minutes have passed.
>
> We assume that established sessions may be in several connectivity states
> from the point of view of the server, typically:
>
> "Live" - a session is genuinely live and can be used for communication.
> "Unresponsive" - the session has a TCP connection associated with it, but
> it unresponsive to pings etc.
> "Resumable" - the session has no TCP session, but 198 resumption was
> negotiated and the session remains available.
>
> We expect that the majority of servers will immediately move a session
> detected as unresponsive into the resumable state by closing the TCP
> session, and starting a (relatively short) timeout.
>
> In the process of doing so, unacknowledged stanzas will be processed for
> push notifications etc as needed, and errors will be sent as appropriate.
>
> Due to network analysis (and "thanks" to a bug in the server which caused
> some useful logging), we were able to examine not only when sessions went
> into the unresponsive state, but also when the client subsequently sent
> traffic on that session. This often happened well after the session had
> fallen into the resumable state - this resulted in an error, as the session
> had been closed.
>
> Having seen the result of this in the logging of the server, we followed
> up by looking for the same logging output on the production system, where
> the majority of users are using WiFi or 4G within hospitals. Coverage is
> often poor, and the WiFi overused, so clinicians often operate on a weak 4G
> signal, or highly contented WiFi. Think FOSDEM.
>
> Again, we observed clients recovering sometimes well after the ping
> timeout had triggered. Had these clients been able to, they could have
> continued to use the same TCP session without any disruption (or, for that
> matter, any additional RTTs re-establishing).
>
> The usual approach here seems to be to increase the timeout required to
> move a session from "live" to "unresponsive" when pinged. However, this has
> the effect of delaying push notifications while the session is, in effect
> in limbo.
>
> Our proposal is that when a session is found to be unresponsive, the
> server starts sending push notifications for unacknowledged (and future)
> messages, but otherwise leaves the session live when resumable. Only after
> a significantly longer timeout should the TCP session be terminated (and at
> that point destroy the session entirely).
>
> This means that a client recovering network after several minutes will
> find the connection still live (in effect), whereas if it never recovers,
> it will still get the push notifications in a timely manner.
>
> There are likely to be downsides with this approach; particularly presence
> state will be badly affected. PSA could help here. Overall, though, we
> believe that this will substantially improve the effective performance of
> C2S over high latency, high contention links.
>
> I hope this is useful!
>
> Dave.
> ___
> 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
___

[Standards] Use of XEP-0198 resumption under adverse network conditions

[Dave Cridland]

Hey all,

We (that is, myself and others from Forward Clinical Ltd, my employer) have
been doing some extensive work to support high latency networks such as
Satellite Links, in relation to our work with UK Defence Medical Services.
Our "long thin" links cover the C2S link.

We believe these findings are more generally useful than just SATCOM - in
particular, we think these will help with the adverse network conditions
found in hospitals (where people keep putting in lifts and lots of cables,
giving lots of blackspots), and general applicability with mobile use of
XMPP.

TL;DR: When the session has a ping timeout, do push notifications, but
otherwise leave it open - mobile clients will often recover after several
minutes have passed.

We assume that established sessions may be in several connectivity states
from the point of view of the server, typically:

"Live" - a session is genuinely live and can be used for communication.
"Unresponsive" - the session has a TCP connection associated with it, but
it unresponsive to pings etc.
"Resumable" - the session has no TCP session, but 198 resumption was
negotiated and the session remains available.

We expect that the majority of servers will immediately move a session
detected as unresponsive into the resumable state by closing the TCP
session, and starting a (relatively short) timeout.

In the process of doing so, unacknowledged stanzas will be processed for
push notifications etc as needed, and errors will be sent as appropriate.

Due to network analysis (and "thanks" to a bug in the server which caused
some useful logging), we were able to examine not only when sessions went
into the unresponsive state, but also when the client subsequently sent
traffic on that session. This often happened well after the session had
fallen into the resumable state - this resulted in an error, as the session
had been closed.

Having seen the result of this in the logging of the server, we followed up
by looking for the same logging output on the production system, where the
majority of users are using WiFi or 4G within hospitals. Coverage is often
poor, and the WiFi overused, so clinicians often operate on a weak 4G
signal, or highly contented WiFi. Think FOSDEM.

Again, we observed clients recovering sometimes well after the ping timeout
had triggered. Had these clients been able to, they could have continued to
use the same TCP session without any disruption (or, for that matter, any
additional RTTs re-establishing).

The usual approach here seems to be to increase the timeout required to
move a session from "live" to "unresponsive" when pinged. However, this has
the effect of delaying push notifications while the session is, in effect
in limbo.

Our proposal is that when a session is found to be unresponsive, the server
starts sending push notifications for unacknowledged (and future) messages,
but otherwise leaves the session live when resumable. Only after a
significantly longer timeout should the TCP session be terminated (and at
that point destroy the session entirely).

This means that a client recovering network after several minutes will find
the connection still live (in effect), whereas if it never recovers, it
will still get the push notifications in a timely manner.

There are likely to be downsides with this approach; particularly presence
state will be badly affected. PSA could help here. Overall, though, we
believe that this will substantially improve the effective performance of
C2S over high latency, high contention links.

I hope this is useful!

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

Re: [Standards] Proposed XMPP Extension: Pre-Authenticated In-Band Registration

[Georg Lukas]

Hi Dave,

* Dave Cridland  [2020-11-03 22:55]:
> This is a very comprehensively written XEP for an initial submission.

Thank you very much for your review!

> My main concern here is the addition of a further IQ during unauthenticated
> state. In the case of every server I've worked with, the IBR (and '78 auth,
> if supported) is hard-coded into the server. This generally feels like a
> security nightmare lurking.

Yeah, I agree with that, and I suppose that the proposed ibr-token
approach needs to be hard-coded in the same way. This is already the
second iteration of a protocol that initially tried to piggy-back the
token as a dedicated element in the original IBR.

The longer-form motivation for ibr-token can be found here:
https://mail.jabber.org/pipermail/standards/2020-January/036848.html

Council discussion at "6) AOB":
https://mail.jabber.org/pipermail/standards/2020-January/036913.html

The discussion of the original extended-IBR is here:
https://mail.jabber.org/pipermail/standards/2018-February/034323.html

My overall hope is that adding a pre-IBR unauthenticated IQ is not going
to increase the attack surface compared to the IBR unauthenticated IQ,
and this was an approach to move forward and implement the principal
idea with the minimum amount of new protocol.

> I would rather move in the other direction, and place the entirety of
> registration inside non-stanza TLEs or (possibly) opting for a
> registration-only authentication before exchanging stanzas.

Well, I'm not an expert on authentication and registration mechanisms,
and I didn't want to become one just for solving an urgent practical
problem, but it looks like there is XEP-0389: Extensible In-Band
Registration, which *also* relies on unauthenticated IQs, that can be
moved into the right direction in the long term, and also some ongoing
work around SASL2.

For now however, I wanted to document the in-the-wild protocol under the
XSF umbrella instead of the already existing inofficial docs at
https://docs.modernxmpp.org/client/invites/

Once somebody has stepped up to implement registration tokens The Right
Way, I'm not going to oppose moving this proposal to Historical.

> Also, this namespace happens to be the same as XEP-0379, which is a trivial
> fix (but, I think, blocking).

This was a deliberate decision, because both XEPs make use of an
invitation token, and the same token could be used either for account
creation (ibr-token) or for subscription (XEP-0379) as defined in
XEP-0401.


Georg
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
++ IRCnet OFTC OPN ||_||


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