[Standards] XEP-0390 improvement proposal: Cashing disco#info for services of user's server

[Sergey Ilinykh]

Problem:
On each client start it necessary to send to disco info to each service
to determine where is upload, muc, socks5 and other useful stuff.
This slowdowns the startup and adds some load to the network and
server. Depending on implementation and service type this is not
obligatory should happen on start but anyway the info is not cached.

XEP-0390 describes caching of disco#info for server/stream itself
and for caps from presences which usually come from contacts.
There is nothing about caps of specific services.

Proposal:
There are many ways to add caps hashes for services but it's hard
to say which one is the most appropriate. I see next ways

1. Add  element to each item of disco#items.
At least the XEP-0030 doesn't forbid it.
2. During computation of caps included in 
consider also caps of services and maybe just xor them.
3. Add caps of services to  as a separate
 elements with "jid" attribute
This will also allow to avoid disco#items in some cases.
4. Invent special disco#caps request similar to disco#items

I personally prefer 1 since together with similar updates to XEP-0230
it will also provide caps update notifications.


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

Re: [Standards] Extending XEP-0085 Chat State Notifications, again

[Sergey Ilinykh]

I like the addition.

Best Regards,
Sergey


пт, 1 мар. 2019 г. в 11:36, Ненахов Андрей :

> This was discussed in July 2018 and, I guess, moved nowhere, but I'll
> raise the issue once again. Any decent messenger bar XMPP based ones have
> capabilities to signal type of user activity beyond just "composing a
> message", but also "recording voice message", "recording video message",
> "uploading file", 
>
> We NEED that in our clients, and, subsequently, we'd prefer it to be an
> XMPP standard.
>
> So far we've extended XEP-0085 by adding a "type" attribute to 
> element:
> from='berna...@shakespeare.lit/pda'
>to='franci...@shakespeare.lit/elsinore'
>type='chat'>
> 
> 
>
> Works OK by us and it does not break any clients with XEP-0085 that we
> know of.
>
> However, last time when this matter was raised, there were objections that
> 0085 is 'final' and therefore we can't change anything because of reasons
> and was essentially discarded. Hope this time it'll be different.
>
> --
> Andrew Nenakhov
> CEO, Redsolution, Inc.
> https://redsolution.com 
> ___
> 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] Proposed XMPP Extension: DNS Queries over XMPP (DoX)

[Sergey Ilinykh]

I guess it's something about accessing forbidden resources from restrictive
corporate networks.

ср, 13 мар. 2019 г., 10:40 Philipp Hörist :

> Whats the use case for this XEP?
> Until now i only needed DNS querys to connect to the XMPP Server, i see
> this XEP is not helping with that as it already needs an active connection
> to the XMPP Server.
>
> regards
> Philipp
> ___
> 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] PR #793 - XEP-0166: Relax transport element requirement

[Sergey Ilinykh]

In response to  Council Minutes 2019-06-19

quote from
https://wiki.xmpp.org/web/XEP-Remarks/XEP-0260:_Jingle_SOCKS5_Bytestreams_Transport_Method


Another problem with early (before accept) transport replace is the fact we
have to send the same offer twice. For example we have S5B and IBB. The
lousy s5b implementation can only gather s5b proxy candidates so it may
fail before we sent initial offer (session/content accept). So after proxy
discovery failure we may want to send transport-replace request to IBB
which will contain everything needed for IBB negotiation (at least block
size). Then we have to repeat transport offer with session/content-accept
which will force the remote party to reinitialize IBB transport what looks
like a bad practice, which may be even worse with other transports. To make
things right it has to be allowed to send session/content-accept without
transport element if it was accepted earlier.

To solve this we have https://github.com/xsf/xeps/pull/793 but may be it
require more actions.
Let's discuss.

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

[Standards] SIMS issues

[Sergey Ilinykh]

Hi

I mostly implemented SIMS in Psi and see next problems

1) The requirement for top-level reference element looks strange.
   In Most of the case when I want to share something, I don't want to
refer to anything.
   If I really want to have a reference I would add it inside of
.

2) Top-level reference doesn't state what has to be in "uri" which is
required

3) Seems like only one  element is allowed while it's quite
common to share multiple files at once with just one description. Sending
each shared file via separate stanza doesn't look to be a good option since
servers often limit sending rate and separate stanzas somehow corrupt
logical scope.

4) I want to use SIMS for voice messages but there is no any metadata for
audio.
   I need at least duration and amplitude diagram there. Something like
following would be really
   nice to have:
   
  tune data here
  0,3,135,237,210,195,243,137,...,4,4,1
   


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

Re: [Standards] SIMS issues

[Sergey Ilinykh]

ср, 19 июн. 2019 г. в 21:33, Ralph Meijer :

> On 19/06/2019 19.46, Sergey Ilinykh wrote:
> > Hi
> >
> > I mostly implemented SIMS in Psi and see next problems
> >
> > 1) The requirement for top-level reference element looks strange.
> > In Most of the case when I want to share something, I don't want to
> > refer to anything.
> > If I really want to have a reference I would add it inside of
> > .
>
> The idea here is very similar to Twitter Entities [1,2]. The primary
> advantage of using References is that you can provide a fallback to
> refer to a location where the media can be found, in case the client
> doesn't support certain media descriptors. I don't think the current
> examples show this very well, but instead of the "view" being referenced
> in the example, you could have a URL to access the picture in a browser.
>

> [1]
> <
> https://developer.twitter.com/en/docs/tweets/data-dictionary/overview/entities-object
> >
> [2]
> <https://developer.twitter.com/en/docs/tweets/da
>
> <https://developer.twitter.com/en/docs/tweets/data-dictionary/overview/extended-entities-object>
> Best Regards,
> Sergey
> ta-dictionary/overview/extended-entities-object
> <https://developer.twitter.com/en/docs/tweets/data-dictionary/overview/extended-entities-object>
> >
>
> Also note that you don't have to use `start` and `end`, if you don't
> want to point to the plain text.
>
>
Then yes the xep has to be updated with use-cases. Since for now only
internal  elements looks usable and it's hard to imagine any
good UX for the top-level one.


>
> > 2) Top-level reference doesn't state what has to be in "uri" which is
> > required
>
> I agree that References still needs a lot of work. However, beyond the
> value needing to be a valid URI, I think everything works. How I used
> it, was providing a URI to retrieve the resource over HTTP. Do you have
> any particular concerns here?
>
>
I rather see it like "most-available-uri". So an application should
prioritize
the sources and select one with highest availibility for top-level
reference.


>
> > 3) Seems like only one  element is allowed while it's
> > quite common to share multiple files at once with just one description.
> > Sending each shared file via separate stanza doesn't look to be a good
> > option since servers often limit sending rate and separate stanzas
> > somehow corrupt logical scope.
>
> But you *can* use multiple References. Would that work for you?
>
>
Can I? It has to be documented.


>
> > 4) I want to use SIMS for voice messages but there is no any metadata
> > for audio.
> > I need at least duration and amplitude diagram there. Something like
> > following would be really
> > nice to have:
> > 
> > tune data here
> > > coding="u8">0,3,135,237,210,195,243,137,...,4,4,1
> > 
>
> That sounds very interesting. I don't remember anyone suggesting a
> metadata format for this before and I didn't get to specify this in my
> previous project which would have eventually needed a format for voice
> messages. So what you could do is first define your own namespace and
> experiment with what works for your use case, and then eventually maybe
> submit it as a new XEP.
>
> Also, I support this element would go inside the  wrapper?
>
>
Correct. I need it inside the . Probably I'll implement it like in
my example.

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

[Standards] XEP-0260 (jingle socks5 transport) candidate-complete event

[Sergey Ilinykh]

Hi

There is a problem with jingle-s5b in the way how it handles additional
candidates sent with transport-info message.

Let's imagine a situation. We have an accepted session. Both sides sent
their host candidates in session-initiate/accept and both sides failed
because of NAT. But one of sides (or maybe both) also had upnp-igd port
binding in progress which would defenitely worked.
Since all current remote candidates failed, both sides send candidate-error
and so finish the transport negotiation with failure not even trying the
candidate coming from upnp which arrived slightly later.
A similar situation is possible with candidate-used leading to selection of
s5b proxy for example instead of nat-assited candidate.

There is a few ways to solve this.

0. The easiest solution is to not send session-initiate/accept until
highest priority candidates are discovered (at least host/NAT-assisted).
This solution though may slowdown the negotiation.

1. Another way. Local party should not sent candidate-used/error if it has
local unacknowledged candidates in including those which discovery is still
in progress. Besides if local party received candidate-error and then sent
a new candidate to remote (respecting candidates priority) then the local
party should forget it received candidate-error from remote and expect new
candidate-error/used to be sent by remote after connection attempts to the
new candidate. Unfortunately it's hard to propose the same against
candidate-used since the remote can stay on previous candidate-used and
send nothing if the new high-priority candidate failed.
While everything above doesn't break compatibility with the spec, for
candidate-used we can also forget the remote already sent candidate-used
and expect the remote will send it again (even if the same) after it
received the new candidate from our local party.

2. Since these double checks of the part 1 complicate a lot the
implementation there has to be an event explicitly telling the remote no
more local candidates will be sent. Let's call it candidate-complete event.
If we add two more restriction from p.1 when the remote must send
candidate-error/used after receiving additional candidates with
transport-info, we come to the state where everything is pretty much clear
and simple.
In this case both parties can send candidate-used/error according to the
current spec. We know exactly when our additional candidates were handled
and when to consider the whole transport negotiation failed. Particularly
the negotiation has be considered completed only when both parties sent
candidate-used/error and candidate-complete.
Probably there is still a room for race conditions but probably it's a
topic for another thread.

Thanks,
Sergey

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

Re: [Standards] XEP-0260 (jingle socks5 transport) candidate-complete event

[Sergey Ilinykh]

That would be perfect indeed.

пн, 29 апр. 2019 г., 18:16 Evgeny :

> On Mon, Apr 29, 2019 at 6:05 PM, Daniel Gultsch 
> wrote:
> > how about sending the upnp as a fallback using transport-replace, with
> > a new transport (new id) of type s5b:1?
>
> Guys, how about switching to TURN instead? Maybe it's time already? ICE
> is not something new anymore. You will really benefit from the code in
> the future if you decide to support some sort of VoIP.
>
> ___
> 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-0260 (jingle socks5 transport) candidate-complete event

[Sergey Ilinykh]

There is a quote from the xep below:

This message MUST contain a  element qualified by the
'urn:xmpp:jingle:transports:s5b:1' namespace, which SHOULD in turn contain
one  element for each SOCKS5 Bytestreams candidate generated by
or known to the responder, but MAY instead be empty if the responder does
not wish to offer any candidates or wishes to send each candidate as the
payload of a transport-info message.

пн, 29 апр. 2019 г., 18:06 Daniel Gultsch :

> Hi,
>
> how about sending the upnp as a fallback using transport-replace, with
> a new transport (new id) of type s5b:1?
>
> I’m not really sure that the method you describe in (1) is legal
> according to the XEP. transport-info isn’t explicitly specified in 260
> and even if it is legal (166 doesn’t forbid it) I have a feeling it
> will be very unexpected to some of the existing implementations.
>
> By the way would love to do some interop assuming you are currently
> implementing Jingle File Transfer in Psi.
>
> cheers
> Daniel
>
> Am Mo., 29. Apr. 2019 um 10:05 Uhr schrieb Sergey Ilinykh <
> rion...@gmail.com>:
> >
> > Hi
> >
> > There is a problem with jingle-s5b in the way how it handles additional
> candidates sent with transport-info message.
> >
> > Let's imagine a situation. We have an accepted session. Both sides sent
> their host candidates in session-initiate/accept and both sides failed
> because of NAT. But one of sides (or maybe both) also had upnp-igd port
> binding in progress which would defenitely worked.
> > Since all current remote candidates failed, both sides send
> candidate-error and so finish the transport negotiation with failure not
> even trying the candidate coming from upnp which arrived slightly later.
> > A similar situation is possible with candidate-used leading to selection
> of s5b proxy for example instead of nat-assited candidate.
> >
> > There is a few ways to solve this.
> >
> > 0. The easiest solution is to not send session-initiate/accept until
> highest priority candidates are discovered (at least host/NAT-assisted).
> This solution though may slowdown the negotiation.
> >
> > 1. Another way. Local party should not sent candidate-used/error if it
> has local unacknowledged candidates in including those which discovery is
> still in progress. Besides if local party received candidate-error and then
> sent a new candidate to remote (respecting candidates priority) then the
> local party should forget it received candidate-error from remote and
> expect new candidate-error/used to be sent by remote after connection
> attempts to the new candidate. Unfortunately it's hard to propose the same
> against candidate-used since the remote can stay on previous candidate-used
> and send nothing if the new high-priority candidate failed.
> > While everything above doesn't break compatibility with the spec, for
> candidate-used we can also forget the remote already sent candidate-used
> and expect the remote will send it again (even if the same) after it
> received the new candidate from our local party.
> >
> > 2. Since these double checks of the part 1 complicate a lot the
> implementation there has to be an event explicitly telling the remote no
> more local candidates will be sent. Let's call it candidate-complete event.
> If we add two more restriction from p.1 when the remote must send
> candidate-error/used after receiving additional candidates with
> transport-info, we come to the state where everything is pretty much clear
> and simple.
> > In this case both parties can send candidate-used/error according to the
> current spec. We know exactly when our additional candidates were handled
> and when to consider the whole transport negotiation failed. Particularly
> the negotiation has be considered completed only when both parties sent
> candidate-used/error and candidate-complete.
> > Probably there is still a room for race conditions but probably it's a
> topic for another thread.
> >
> > Thanks,
> > Sergey
> >
> > // Psi IM dev
> > ___
> > 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 mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] PR #793 - XEP-0166: Relax transport element requirement

[Sergey Ilinykh]

I agree. The empty transport elements is one of the approaches. I thought
about it. But then I thought "if every transport may declare it's own set
of obligatory transport attributes then why should I parse transport
elements at all figuring out whichi attributes are required and which not
if it doesn't bring any value and some other jingle action already allow
the absence of the transport element".

Best Regards,
Sergey


ср, 26 июн. 2019 г. в 13:43, Philipp Hancke :

> Am 22.06.19 um 17:18 schrieb Sergey Ilinykh:
> > In response to  Council Minutes 2019-06-19
> >
> > quote from
> >
> https://wiki.xmpp.org/web/XEP-Remarks/XEP-0260:_Jingle_SOCKS5_Bytestreams_Transport_Method
> >
> >
> > Another problem with early (before accept) transport replace is the fact
> we
> > have to send the same offer twice. For example we have S5B and IBB. The
> > lousy s5b implementation can only gather s5b proxy candidates so it may
> > fail before we sent initial offer (session/content accept). So after
> proxy
> > discovery failure we may want to send transport-replace request to IBB
> > which will contain everything needed for IBB negotiation (at least block
> > size). Then we have to repeat transport offer with session/content-accept
> > which will force the remote party to reinitialize IBB transport what
> looks
> > like a bad practice, which may be even worse with other transports. To
> make
> > things right it has to be allowed to send session/content-accept without
> > transport element if it was accepted earlier.
> >
> > To solve this we have https://github.com/xsf/xeps/pull/793 but may be it
> > require more actions.
> > Let's discuss.
>
> Moving over from github. Peter, Lance and me looked at a very similar
> case back in 2015, fallback from ice-udp to raw-udp. It also does a
> transport-replace before session-accept.
>
>https://xmpp.org/extensions/xep-0371.html#fallback
> has the full protocol flow. Its a bit unclear to me now why Romeo would
> send a ice-udp transport to the gateway which is unlikely to announce
> this in disco... (which I assume is the way to pick the transport even
> though 0166 is silent here)
>
>
> We kept this within the current jingle specification by including an
> empty namespaced
>
> in the session-accept (example 15) which basically says "reminder: we
> agreed on this transport, hopefully you remember the details".
>
> For IBB I would recommend a similar thing but keeping the sid attribute,
> the initiator can then verify that this refers to an already active
> session that does not need to be reinitialized.
>
> (I just hope we're using this pattern consistently...)
>
> cheers
>
> Philipp
> (and thanks for the poke 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
___

Re: [Standards] SIMS issues

[Sergey Ilinykh]

Thanks for the feedback Jonas.

Honestly I already thought about this after implementation and I agree with
you.
Removing "coding" in favor of always base64(u8) would make things way
easier and still sufficient.
And I'm fine with 

---

Regarding references. Andrew Nenakhov gave me a good idea what to reference
to when want to just an audio message.
It's a text for clients which do not support SIMS. For example it can be an
HTTP link to the audio record or something
like "Go and install another client to listen this" in case there is only
s5b stream available.
So when SIMS-capable client renders this, it removes the referenced text.
As far as I remember Andrew even added
a special attribute the references where they have to be removed or not. So
I believe his ideas could be applied here.

Best Regards,
Sergey


сб, 7 сент. 2019 г. в 14:29, Jonas Schäfer :

> On Mittwoch, 19. Juni 2019 19:46:02 CEST Sergey Ilinykh wrote:
> > Hi
> >
> > I mostly implemented SIMS in Psi and see next problems
> >
> > 1) The requirement for top-level reference element looks strange.
> >In Most of the case when I want to share something, I don't want to
> > refer to anything.
> >If I really want to have a reference I would add it inside of
> > .
> >
> > 2) Top-level reference doesn't state what has to be in "uri" which is
> > required
> >
> > 3) Seems like only one  element is allowed while it's
> quite
> > common to share multiple files at once with just one description. Sending
> > each shared file via separate stanza doesn't look to be a good option
> since
> > servers often limit sending rate and separate stanzas somehow corrupt
> > logical scope.
> >
> > 4) I want to use SIMS for voice messages but there is no any metadata for
> > audio.
> >I need at least duration and amplitude diagram there. Something like
> > following would be really
> >nice to have:
> >
> >   tune data
> here
> >coding="u8">0,3,135,237,210,195,243,137,...,4,4,1
> > 
>
> Nitpick: If you are going to implement this and intend on standardising
> it,
> may I suggest to use base64-encoded u8 bytes instead of the proposed
> string
> syntax? It will be smaller by approximately 63% for uniformly distributed
> amplitudes and by approximately 33% for all-zeros (worst-case). (I am also
> fairly certain that for the preview, u8 is fully sufficient.) (base64
> starts
> to be consistently smaller (in the all-zeros worst-case) once you have
> more
> than 5 samples.)
>
> Another Nitpick: From your description, it is more like an 
> preview instead of a  (which implies something like a Fourier
> transform or another way to obtain per-frequency values).
>
> kind regards,
> Jonas___
> 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] Support for stickers (custom emojis)

[Sergey Ilinykh]

> I'm not sure what you mean. The "begin" and "end" attributes on the
>  element can encapsulate the shortname of the sticker.

I mean where the encapsulated text has to be somehow presented to the user
or fully replaced with the sticker as if it never was there.
I believe in some cases (not stickers) the text has to be preserved for
SIMS.

Best Regards,
Sergey


чт, 17 окт. 2019 г. в 15:43, JC Brand :

> On Thu, Oct 17, 2019 at 03:05:32PM +0300, Sergey Ilinykh wrote:
> >Doesn't SIMS ([1]https://xmpp.org/extensions/xep-0385.html) resolve
> all
> >the concerns yet?
>
> Yes, SIMS is more comprehensive than my example. It's still uses a XEP-0372
> reference, so it's conceptually similar.
>
> >We can have a  with cid: uri too.
>
> yep.
>
> We could probably also specify under  some JID which can return
> the BOB
> data as Marvin suggested.
>
> >The only thing is missed as for me is an attribute where the
> referenced
> >text has to be removed or not.
> >Best Regards,
>
> I'm not sure what you mean. The "begin" and "end" attributes on the
>  element can encapsulate the shortname of the sticker.
>
> JC
>
> >Sergey
> >чт, 17 окт. 2019 г. в 14:24, Marvin W <[2]x...@larma.de>:
> >
> >  Hi,
> >
> >  Regarding your proposal:
> >  - You should still add a hash in the reference somehow so that
> clients
> >  *can* cache entries (even if you won't do it in Converse)
> >  - I already dislike the fact that we do HTTP requests to arbitrary
> >  servers for file transfers, as we might be leaking IP addresses in
> such
> >  cases. In the case of Converse, you are likely to get into GDPR
> issues
> >  when doing so without explicit user consent (and you don't want
> explicit
> >  user consent for every emoji). There is a reason why many
> e-Mail-Clients
> >  don't render remote content in e-Mails...
> >  - When this is combined with body-only e2e-encryption, you are
> leaking
> >  information as I guess you don't envision the emoji to be encrypted
> for
> >  each e2e session individually.
> >
> >  You can probably solve the second issue mentioned above and the
> issue
> >  with http files by proxying the image request through the server
> hosting
> >  Converse (which is what other popular sites that allow arbitrary
> http
> >  links like GitHub do). But I guess you don't want to do that.
> >
> >  Regarding your issues with using BOB:
> >  - BOB does not depend on XHTML-IM. 0231 §2.2 specifically says that
> "any
> >  appropriate format can be used" to share the CID. This means it is
> also
> >  possible to use it in 0372 references (as you suggest to do just
> without
> >  http).
> >  - BOB does not require the sender to provide the file referenced by
> the
> >  CID 0231 §2.1 says that you can send the IQ to request the bytes to
> >  "potentially some other entity". If you don't expect the sending
> client
> >  to provide the file, it doesn't need to cache all stickers and it
> >  doesn't need to be online.
> >
> >  Marvin
> >
> >  On 10/17/19 12:07 PM, JC Brand wrote:
> >  > Hello
> >  >
> >  > I'm currently working on adding support for non-unicode emojis to
> >  Converse.js.
> >  >
> >  > Currently, users can't upload their own images to be used for
> custom
> >  emojis,
> >  > mostly because Converse is a thin client with no backend support
> for
> >  it.
> >  >
> >  > So to add custom emojis, the web host needs to edit a emojis.json
> file
> >  > to add new entries with URLs pointing to the actual images.
> >  >
> >  > Concerning compatibility with other clients, I've discussed it
> with
> >  edhelas
> >  > and he told me he uses XEP-0231 BOB for sending stickers.
> >  >
> >  > There are a few reasons why I'm not keen on using BOB:
> >  >
> >  > - BOB depends on XHTML-IM which is deprecated. Converse.js doesn't
> >  support it
> >  >and I'm reluctant to add support just for this.
> >  > - BOB mentions that binary data should be smaller than 1KB. Not
> sure
> >  how
> >  >relevant that still is, but it discourages me from sending
> larger
> >  amounts.
> >  > - The sending client needs to maintai

Re: [Standards] Support for stickers (custom emojis)

[Sergey Ilinykh]

Doesn't SIMS (https://xmpp.org/extensions/xep-0385.html) resolve all the
concerns yet?
We can have a  with cid: uri too.

The only thing is missed as for me is an attribute where the referenced
text has to be removed or not.

Best Regards,
Sergey


чт, 17 окт. 2019 г. в 14:24, Marvin W :

> Hi,
>
> Regarding your proposal:
> - You should still add a hash in the reference somehow so that clients
> *can* cache entries (even if you won't do it in Converse)
> - I already dislike the fact that we do HTTP requests to arbitrary
> servers for file transfers, as we might be leaking IP addresses in such
> cases. In the case of Converse, you are likely to get into GDPR issues
> when doing so without explicit user consent (and you don't want explicit
> user consent for every emoji). There is a reason why many e-Mail-Clients
> don't render remote content in e-Mails...
> - When this is combined with body-only e2e-encryption, you are leaking
> information as I guess you don't envision the emoji to be encrypted for
> each e2e session individually.
>
> You can probably solve the second issue mentioned above and the issue
> with http files by proxying the image request through the server hosting
> Converse (which is what other popular sites that allow arbitrary http
> links like GitHub do). But I guess you don't want to do that.
>
> Regarding your issues with using BOB:
> - BOB does not depend on XHTML-IM. 0231 §2.2 specifically says that "any
> appropriate format can be used" to share the CID. This means it is also
> possible to use it in 0372 references (as you suggest to do just without
> http).
> - BOB does not require the sender to provide the file referenced by the
> CID 0231 §2.1 says that you can send the IQ to request the bytes to
> "potentially some other entity". If you don't expect the sending client
> to provide the file, it doesn't need to cache all stickers and it
> doesn't need to be online.
>
> Marvin
>
> On 10/17/19 12:07 PM, JC Brand wrote:
> > Hello
> >
> > I'm currently working on adding support for non-unicode emojis to
> Converse.js.
> >
> > Currently, users can't upload their own images to be used for custom
> emojis,
> > mostly because Converse is a thin client with no backend support for it.
> >
> > So to add custom emojis, the web host needs to edit a emojis.json file
> > to add new entries with URLs pointing to the actual images.
> >
> > Concerning compatibility with other clients, I've discussed it with
> edhelas
> > and he told me he uses XEP-0231 BOB for sending stickers.
> >
> > There are a few reasons why I'm not keen on using BOB:
> >
> > - BOB depends on XHTML-IM which is deprecated. Converse.js doesn't
> support it
> >and I'm reluctant to add support just for this.
> > - BOB mentions that binary data should be smaller than 1KB. Not sure how
> >relevant that still is, but it discourages me from sending larger
> amounts.
> > - The sending client needs to maintain a cache of all sent stickers.
> > - AFAICT, when receiving an uncached BOB message via MAM and the sending
> client
> >is offline, then you can't get the image data.
> >
> > Instead, I propose that we use XEP-0372 references to indicate that a
> > particular shortname (e.g. :dancingpanda:) should be replaced with an
> image.
> >
> > For example:
> >
> >   >  I feel like dancing! :dancingpanda:
> >   >  begin="21"
> >  end="35"
> >  type="data"
> >  uri="https://images.com/dancingpanda"/>
> >  
> >
> > I'm not sure whether "type" should be "data", seems a bit too generic
> for me,
> > perhaps it could be something else?
> >
> > Some criticisms of this approach from edhelas:
> >
> > - HTTP images can be sent to a webchat client served over HTTPS
> > - There's no size limit, so users can send links to very large stickers
> >
> > Concerning the first criticism, a client can choose to not render HTTP
> > images inline and instead make the shortname a link which opens the
> image in a
> > new tab. Not ideal, but a compromise for the privacy and security
> conscious.
> >
> > For the second I don't have a good answer.
> >
> > That said, I currently still prefer my suggestion to using BOB. I'd be
> > interested to hear your feedback and suggestions.
> >
> > Regards
> > JC
> >
> >
> > ___
> > 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 mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org

[Standards] XEP-0371 (Jingle ICE): update RFC 5245 -> RFC 8445

[Sergey Ilinykh]

https://github.com/xsf/xeps/pull/905

PR Changes:

   1. RFC 5245 is replaced with RFC 8445
   2. Aggressive nomination is not supported anymore
   3. remote-candidate is now MUST to mimic ICE SDP RFC
   4. Now remote-candidate has to be send for all components at once when
   ICE for media stream has completed
   5. Namespace version was updated because of incompatible changes
   6. Wrong reference to RFC 6455 was replaced with correct one: RFC 6544

Let's review / discuss / fix / merge.

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

Re: [Standards] XEP-0371 (Jingle ICE): update RFC 5245 -> RFC 8445

[Sergey Ilinykh]

Hi Jonathan,

Ufrag+pwd are changed on ICE restart and they are sent with each
transport-info message. The params perfectly determine the generation. And
also special "generation" attribute is sent with each candidate. So I don't
understand what you mean.

пт, 13 мар. 2020 г., 0:48 Jonathan Lennox :

> One major comment:
>
> 1. There is (and has always been) a semantic hole in ICE restart with
> Jingle, because transport-info is a unilateral message, unlike SDP
> offer/answer which is transactional.
>
> Specifically, there's no way for a Jingle endpoint to know for certain
> which
> generation of its local candidates should be matched with a set of
> candidates received in a transport-info message.
>
> Perhaps some sort of remote-generation attribute is necessary for
> candidates
> sent in response to a peer's candidates?
>
> On Friday, March 13 2020, "Sergey Ilinykh" wrote to "XMPP Standards"
> saying:
>
> > https://github.com/xsf/xeps/pull/905
> >
> > PR Changes:
> >
> >  1. RFC 5245 is replaced with RFC 8445
> >  2. Aggressive nomination is not supported anymore
> >  3. remote-candidate is now MUST to mimic ICE SDP RFC
> >  4. Now remote-candidate has to be send for all components at once when
> ICE for
> > media stream has completed
> >  5. Namespace version was updated because of incompatible changes
> >  6. Wrong reference to RFC 6455 was replaced with correct one: RFC 6544
> >
> > Let's review / discuss / fix / merge.
> >
> > Best Regards,
> > Sergey
> > ___
> > Standards mailing list
> > Info: https://mail.jabber.org/mailman/listinfo/standards
> > Unsubscribe: standards-unsubscr...@xmpp.org
> > ___
>
> --
> Jonathan Lennox
> len...@cs.columbia.edu
> ___
> 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-0167: What happened with

[Sergey Ilinykh]

For bundling we already have https://xmpp.org/extensions/xep-0338.html
Only mux is w/o XEP.

Best Regards,
Sergey


пн, 13 апр. 2020 г. в 14:41, Daniel Gultsch :

> Am Mo., 13. Apr. 2020 um 11:33 Uhr schrieb Sergey Ilinykh <
> rion...@gmail.com>:
> >
> > I can't say anything about the history. But I like Jitsi's
> implementation and will add support to Psi soon.
>
> Bundling and rtcp muxing is not the same thing. They are often used
> together but not always.
> Is there any down side in being explicit about it with an extra
>  element?
> ___
> 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-0167: What happened with

[Sergey Ilinykh]

I can't say anything about the history. But I like Jitsi's implementation
and will add support to Psi soon.

Best Regards,
Sergey


пн, 13 апр. 2020 г. в 14:23, Daniel Gultsch :

> Hi,
>
> webrtc uses rtcp-mux but to my knowledge XMPP has no way of signaling
> that a party wants to use that.
>
> Jitsi apparently just assumes that rtcp-mux is being used when bundles
> are used [1] however that isn’t necessarily correct in all cases.
>
> Philipp Hancke apparently wrote a patch for XEP-0167 that introduced
>  as an element in the description (based on what Google
> did) in 2014 [2]. However apparently that didn’t get merged.
>
> Anyone remember why? Was this just forgotten or was this replaced with
> something else? Or deemed unnecessary for some reason?
>
> If not I'd just create a new PR with that old patch.
>
> cheers
> Daniel
>
>
>
> [1]: https://github.com/jitsi/jitsi-videobridge/blob/master/doc/bundle.md
> [2]: https://wiki.xmpp.org/web/User:Fippo#mapping_a.3Drtcp-mux
> ___
> 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-0371 (Jingle ICE): update RFC 5245 -> RFC 8445

[Sergey Ilinykh]

>
>
> I'm still not sure if it solves the problem if one end sends two "restart"
> transport-infos in rapid succession.  It'll receive a "restart"
> transport-info
> in response, but which one should it pair it with?
>

according to ufrag.

so one end sends (ep1) restart, the other end (ep2) receives it, sends back
iq result and assuming it has already lots ready-to-use candidates it sends
transport-info back with new ep1/ep2 ufrag combination according to RFC
(new local generated and one from ep1 transport-info message).
The ep1 side by this time already sent another "restart", so ufrag is
already
different. On receive transport-info from ep2, ep1 checks ep1 part of ufrag
 and sees it doesn't match with anything. So it abandons the transport-info
message from ep2 just sending back iq result.
Eventually ep2 will receive second restart message with the updated ufrag,
so ep2 will abandon previous restart procedure and migrate to the new one.
ep2 will send back new transport-info with the new ufrag and after all it
will
be recognized by ep1.


> I'm also not sure how well this would work with backward compatibility.
> Are
> you assuming entirely separate handling for namespace ice:1 from namespace
> ice:0?
>

Oh well. That's something more complicated. According to Philipp Hancke we
should not worry about backward compatibility but should worry about
compatibility with other software which might not support the new RFC.
In fact I didn't get this idea initially but it make more sense for me now.

So there is a couple of points to mention:
1) We need compatibility with browsers since they have the best and
the simplest support for webrtc. So easy to write a client supporting
Jingle ICE.
Therefore old RFC5245 has to be supported somehow since some browsers
lack support for RFC 8445.
RFC 8445 describes "ice2" option for this.
2) XEP-0371 is not released and not wide-spread. So it's fine for the XEP
to take changes without caring much about backward compatibility. So
even
the namespace change is probably not necessary. But here I'd like to
understand
what community thinks about this.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0371 (Jingle ICE): update RFC 5245 -> RFC 8445

[Sergey Ilinykh]

>
> An interface switches addresses, so you send transport-info with
> generation X.
>
> The interface switches addresses back, so you then send transport-info with
> generation X+1.
>
> You receive transport-info with generation Y.
>
> Should you pair the generation Y candidates with generation X, or with
> generation X+1?  If you choose differently than the remote endpoint did,
> connectivity checking will fail, because your ufrag and password values
> will
> be wrong.
>

I see two issues here:

   1. How we differentiate a response to X+0 from ICE restart from remote if
   ufrag is already forgotten for X+0 on the local side
   2. How a client should handle transport-info message with unknown ufrag


I'll update the PR with next changes:

1.a. ICE restart MUST include "restart" attribute in transport-info message
1.b. If both sides are trying to do ICE restart in the same time
(transport-info with
   restart already sent by both sides) session initiator will send
tie-break iq error.
2. transport-info message without "restart" attribute but with unknown
ufrag has
to be silently dropped right after iq result because it's hard to say
where it's
an error or some outdated data.

Does it solve the problem?



>
> > пт, 13 мар. 2020 г., 0:48 Jonathan Lennox :
> >
> > One major comment:
> >
> > 1. There is (and has always been) a semantic hole in ICE restart with
> > Jingle, because transport-info is a unilateral message, unlike SDP
> > offer/answer which is transactional.
> >
> > Specifically, there's no way for a Jingle endpoint to know for
> certain
> > which
> > generation of its local candidates should be matched with a set of
> > candidates received in a transport-info message.
> >
> > Perhaps some sort of remote-generation attribute is necessary for
> > candidates
> > sent in response to a peer's candidates?
> >
> > On Friday, March 13 2020, "Sergey Ilinykh" wrote to "XMPP Standards"
> > saying:
> >
> > > https://github.com/xsf/xeps/pull/905
> > >
> > > PR Changes:
> > >
> > >  1. RFC 5245 is replaced with RFC 8445
> > >  2. Aggressive nomination is not supported anymore
> > >  3. remote-candidate is now MUST to mimic ICE SDP RFC
> > >  4. Now remote-candidate has to be send for all components at once
> when
> > ICE for
> > > media stream has completed
> > >  5. Namespace version was updated because of incompatible changes
> > >  6. Wrong reference to RFC 6455 was replaced with correct one: RFC
> 6544
> > >
> > > Let's review / discuss / fix / merge.
> > >
> > > Best Regards,
> > > Sergey
> > > ___
> > > Standards mailing list
> > > Info: https://mail.jabber.org/mailman/listinfo/standards
> > > Unsubscribe: standards-unsubscr...@xmpp.org
> > > ___
> >
> > --
> > Jonathan Lennox
> > len...@cs.columbia.edu
> > ___
> > 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
> > ___
>
> --
> Jonathan Lennox
> len...@cs.columbia.edu
> ___
> 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-0371 (Jingle ICE): update RFC 5245 -> RFC 8445

[Sergey Ilinykh]

>
> > I'm still not sure if it solves the problem if one end sends two
> "restart"
> > transport-infos in rapid succession.  It'll receive a "restart"
> > transport-info
> > in response, but which one should it pair it with?
> >
> >
> > according to ufrag.
> >
> > so one end sends (ep1) restart, the other end (ep2) receives it, sends
> back
> > iq result and assuming it has already lots ready-to-use candidates it
> sends
> > transport-info back with new ep1/ep2 ufrag combination according to RFC
> > (new local generated and one from ep1 transport-info message).
> > The ep1 side by this time already sent another "restart", so ufrag is
> already
> > different. On receive transport-info from ep2, ep1 checks ep1 part of
> ufrag
> >  and sees it doesn't match with anything. So it abandons the
> transport-info
> > message from ep2 just sending back iq result.
> > Eventually ep2 will receive second restart message with the updated
> ufrag,
> > so ep2 will abandon previous restart procedure and migrate to the new
> one.
> > ep2 will send back new transport-info with the new ufrag and after all
> it will
> > be recognized by ep1.
>
> But the two endpoints' ufrags are unrelated, and generated randomly.  How
> does seeing the remote ufrag help me associate it with one of my a local
> ones?
>

Sorry, you are right. I confused with auth in STUN binding requests. Let me
think
about it. I'll update the thread when have something in mind.

>
> > I'm also not sure how well this would work with backward
> compatibility.
> > Are
> > you assuming entirely separate handling for namespace ice:1 from
> namespace
> > ice:0?
> >
> >
> > Oh well. That's something more complicated. According to Philipp Hancke
> we
> > should not worry about backward compatibility but should worry about
> > compatibility with other software which might not support the new RFC.
> > In fact I didn't get this idea initially but it make more sense for me
> now.
> >
> > So there is a couple of points to mention:
> > 1) We need compatibility with browsers since they have the best and
> > the simplest support for webrtc. So easy to write a client supporting
> > Jingle ICE.
> > Therefore old RFC5245 has to be supported somehow since some browsers
> > lack support for RFC 8445.
> > RFC 8445 describes "ice2" option for this.
>
> Browsers, of course, are doing JSEP which is SDP offer/answer, so the
> translation layer from Jingle still has to handle the transactioning.
>
> --
> Jonathan Lennox
> len...@cs.columbia.edu
> ___
> 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-0371 (Jingle ICE): update RFC 5245 -> RFC 8445

[Sergey Ilinykh]

>
> >
>> > I'm still not sure if it solves the problem if one end sends two
>> "restart"
>> > transport-infos in rapid succession.  It'll receive a "restart"
>> > transport-info
>> > in response, but which one should it pair it with?
>> >
>> >
>> > according to ufrag.
>> >
>> > so one end sends (ep1) restart, the other end (ep2) receives it, sends
>> back
>> > iq result and assuming it has already lots ready-to-use candidates it
>> sends
>> > transport-info back with new ep1/ep2 ufrag combination according to RFC
>> > (new local generated and one from ep1 transport-info message).
>> > The ep1 side by this time already sent another "restart", so ufrag is
>> already
>> > different. On receive transport-info from ep2, ep1 checks ep1 part of
>> ufrag
>> >  and sees it doesn't match with anything. So it abandons the
>> transport-info
>> > message from ep2 just sending back iq result.
>> > Eventually ep2 will receive second restart message with the updated
>> ufrag,
>> > so ep2 will abandon previous restart procedure and migrate to the new
>> one.
>> > ep2 will send back new transport-info with the new ufrag and after all
>> it will
>> > be recognized by ep1.
>>
>> But the two endpoints' ufrags are unrelated, and generated randomly.  How
>> does seeing the remote ufrag help me associate it with one of my a local
>> ones?
>>
>
> Sorry, you are right. I confused with auth in STUN binding requests. Let
> me think
> about it. I'll update the thread when have something in mind.
>

Let's make it more transactional then. Basically that's what 
designed for.
The idea is to drop incoming transport-info messages if they are received
before
local session start/restart is confirmed with iq result by the other party.
The other party then can resend these candidates again (RFC allows it).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0371 (Jingle ICE): update RFC 5245 -> RFC 8445

[Sergey Ilinykh]

Updated change-list after PR update:


   - RFC 5245 is replaced with RFC 8445
   - Introduced ice2 transport attribute for backward compatibility
   - Clarified ICE restart procedure
   - remote-candidate is now MUST to mimic ICE SDP RFC
   - Now remote-candidate is sent on media stream established for all
   components at once
   - Wrong reference to RFC 6455 was replaced with correct one: RFC 6544


Best Regards,
Sergey


вт, 17 мар. 2020 г. в 12:54, Sergey Ilinykh :

> > who is implementing 8445?
> >
> > Firefox only implements aggressive nomination.
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1034964 has some details.
>
> Does it matter? Do you think the new standard is going to be abandoned?
> Do you think XMPP should implement the standard only after other big
> players?
> But if the compatibility matters a lot for this deferred XEP, maybe ice:0
> vs ice:1
> in the namespace is a good indicator. In this case maybe it's good to
> split the PR into two
> (rfc-related and remote-candidates), and maybe add some disco features.
> wdyt?
>
> > remote-candidate is a very sip-ish concept not even implemented by
> webrtc.org.
>
> But the idea behind is applicable to XMPP. Why shouldn't we take it? I
> don't like those MAY/SHOULD etc,
> they add a lot of complexity to the code. If ICE SDP says MUST, I think it
> has to be MUST for us too
> since we are trying to mimic SDP everywhere.
>
> > I don't think bumping the namespace is practical until deployment is
> more wide-spread.
>
> I can agree here. But it would be nice to hear more thoughts from those
> who already implemented this XEP.
>
>
> вт, 17 мар. 2020 г. в 12:14, Philipp Hancke :
>
>> Am 12.03.20 um 22:30 schrieb Sergey Ilinykh:
>> > https://github.com/xsf/xeps/pull/905
>> >
>> > PR Changes:
>> >
>> > 1. RFC 5245 is replaced with RFC 8445
>>
>> who is implementing 8445?
>>
>> > 2. Aggressive nomination is not supported anymore
>>
>> Firefox only implements aggressive nomination.
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1034964 has some details.
>>
>> > 3. remote-candidate is now MUST to mimic ICE SDP RFC
>> > 4. Now remote-candidate has to be send for all components at once
>> when
>> > ICE for media stream has completed
>>
>> remote-candidate is a very sip-ish concept not even implemented by
>> webrtc.org.
>>
>> > 5. Namespace version was updated because of incompatible changes
>>
>> I don't think bumping the namespace is practical until deployment is
>> more wide-spread.
>>
>> > 6. Wrong reference to RFC 6455 was replaced with correct one: RFC
>> 6544
>>
>> good catch!
>> ___
>> 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-0371 (Jingle ICE): update RFC 5245 -> RFC 8445

[Sergey Ilinykh]

> who is implementing 8445?
>
> Firefox only implements aggressive nomination.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1034964 has some details.

Does it matter? Do you think the new standard is going to be abandoned?
Do you think XMPP should implement the standard only after other big
players?
But if the compatibility matters a lot for this deferred XEP, maybe ice:0
vs ice:1
in the namespace is a good indicator. In this case maybe it's good to split
the PR into two
(rfc-related and remote-candidates), and maybe add some disco features.
wdyt?

> remote-candidate is a very sip-ish concept not even implemented by
webrtc.org.

But the idea behind is applicable to XMPP. Why shouldn't we take it? I
don't like those MAY/SHOULD etc,
they add a lot of complexity to the code. If ICE SDP says MUST, I think it
has to be MUST for us too
since we are trying to mimic SDP everywhere.

> I don't think bumping the namespace is practical until deployment is more
wide-spread.

I can agree here. But it would be nice to hear more thoughts from those who
already implemented this XEP.


вт, 17 мар. 2020 г. в 12:14, Philipp Hancke :

> Am 12.03.20 um 22:30 schrieb Sergey Ilinykh:
> > https://github.com/xsf/xeps/pull/905
> >
> > PR Changes:
> >
> > 1. RFC 5245 is replaced with RFC 8445
>
> who is implementing 8445?
>
> > 2. Aggressive nomination is not supported anymore
>
> Firefox only implements aggressive nomination.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1034964 has some details.
>
> > 3. remote-candidate is now MUST to mimic ICE SDP RFC
> > 4. Now remote-candidate has to be send for all components at once
> when
> > ICE for media stream has completed
>
> remote-candidate is a very sip-ish concept not even implemented by
> webrtc.org.
>
> > 5. Namespace version was updated because of incompatible changes
>
> I don't think bumping the namespace is practical until deployment is
> more wide-spread.
>
> > 6. Wrong reference to RFC 6455 was replaced with correct one: RFC
> 6544
>
> good catch!
> ___
> 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] Bookmarks and autojoin issues

[Sergey Ilinykh]

Another perspective for profiles is work/life balance. Work/life MUCs or
anything else fitting this concept.

Particularly in Psi I've already added some options allowing to ignore some
autojoining mucs for example at work or local-only (not stored on a server)
bookmarks.

Best Regards,
Sergey


вс, 24 мая 2020 г. в 01:56, Sam Whited :

> On Sat, May 23, 2020, at 18:41, Mathieu Pasquet wrote:
> > In a multi-client scenario however, that quickly changes as you
> > probably do not want the same view everywhere.
>
> I disagree, I always want exactly the same view everywhere. Otherwise I
> inevitably leave my desk and then try to look up something on my phone
> that someone mentioned earlier and can't find it because I'm not
> actually joined to that room. I do not know if my view on this is more
> prevalent than people who want their phone joined to different rooms or
> not, but I definitely want to dispute the "probably do not want the same
> view" in the previous message.
>
> —Sam
>
> --
> Sam Whited
> ___
> 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] Call for Experience: XEP-0050: Ad-Hoc Commands

[Sergey Ilinykh]

> The XEP Editor would like to Call for Experience with XEP-0050 before
> presenting it to the Council for advancing it to Final status.
>
>
> During the Call for Experience, please answer the following questions:
>
> 1. What software has XEP-0050 implemented? Please note that the
> protocol must be implemented in at least two separate codebases (at
> least one of which must be free or open-source software) in order to
> advance from Draft to Final.
>
> Psi. It's there for decades.


> 2. Have developers experienced any problems with the protocol as
> defined in XEP-0050? If so, please describe the problems and, if
> possible, suggested solutions.
>

> 3. Is the text of XEP-0050 clear and unambiguous? Are more examples
> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate?
> Have developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.
>
> Probably Remko Troncon or Kev can tell us this story.
(Psi git history starts later)


> If you have any comments about advancing XEP-0050 from Draft to Final,
> please provide them by the close of business on 2020-06-09. After the
> Call for Experience, this XEP might undergo revisions to address
> feedback received, after which it will be presented to the XMPP
> Council for voting to a status of Final.
>

 I haven't heard any complains about XEP-0050 for years but also I haven't
reviewed it close enough.
Even so I think the XEP serves its purpose well.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Thoughts on XEP-0385 Stateless Inline Media Sharing

[Sergey Ilinykh]

What about a slightly different scenario?

Romeo sees a funny picture on funnypics.com, copies it to a messenger's
input field. The messenger prefetches the whole picture, generates a
thumbnail (at least it's impossible to have a thumbnail without fetching
everything), computes hashes and then sends. Optionally the picture can be
put to a local cache and also become available over Jingle and other
transfer methods.
Now Juliet having a thumbnail knows exactly if she wants to download a
whole size picture.

But this is just about pictures. Probably sharing a bluray video by the
link from the web won't work this well in this case. So I tend to agree
having alternative  integrity checks looks reasonable. Also sharing
arbitrary files via SIMS, not just multimedia, may require splitting the
presentation and sharing into two dedicated XEPs.

Best Regards,
Sergey


пт, 2 июл. 2021 г. в 13:17, JC Brand :

> Hi everyone
>
>
> I've been reading XEP-0385 SIMS with an eye towards potentially
> implementing it, when I noticed that a XEP-0300 hash is required, in
> order to allow integrity checking and caching.
>
> In the introduction of SIMS, the following is written:
> "This proposal aims to provide a protocol that will enable XMPP clients
> to implement a great user experience (UX) around the process of sharing
> media in conversations."
>
> I think making inclusion of the file hash mandatory is at odds with that
> goal, the reason being that a lot of the media being shared in chats is
> shared as URLs to 3rd parties where the media is hosted.
> In other words, the sharer of the media doesn't necessarily know the
> hash of the media because it was never on their own machine to begin with.
>
> Here's the use-case I have in mind:
>
> Romeo sees a funny picture on funnypics.com. He right-clicks on the
> picture, copies the URL and sends it to Juliet. Before the message is
> sent, Romeo's client does an HTTP HEAD request, to get information on
> the URL, and learns that its an image.
>
> Here's the response:
>
> HTTP/2 200
> last-modified: Fri, 02 Jul 2021 02:46:55 GMT
> etag: "a1d5ea7e796f5da6980bed86a8396664"
> content-type: image/jpeg
> cache-control: public, max-age=31536000
> accept-ranges: bytes
> date: Fri, 02 Jul 2021 06:44:39 GMT
> access-control-allow-methods: GET, OPTIONS
> access-control-allow-origin: *
> content-length: 110220
>
> The "content-type" header can be used for the SIMS  tag and
> the "content-length" header for the .
>
> The server also responds with an "etag" header, which can be used for
> caching, but unfortunately not for integrity checking, since the method
> by which it's generated is not specified.
> If the etag is passed along via SIMS (instead of the hash), the
> receiving client could also check whether it matches what's returned by
> the webserver, although I'm not sure what conclusions can be drawn if
> they don't match.
>
> Before someone says that this scenario is not relevant to what SIMS is
> trying to do, please note that this problem also occurs when someone
> shares a file via HTTP upload and then the receiving party copies and
> pastes that URL in a message to someone else. Perhaps an intelligent
> enough client might go and get the hash from the original SIMS data and
> then add that to the newly sent message, but that seems a bit contrived
> to me and might not always be feasible.
>
> So... back to the scenario. After Romeo's client has received the HEAD
> headers, it can then construct a SIMS element with it.
>
>
> Look
> at this funny cat
>
> pictureimage/jpegicanhazcheeseburger.jpg110220 http://jabber.org/protocol/shim'>some-long-opaque-stringFat
>
> cat that looks like it wants a
>
> cheeseburger https://funnypics.com/icanhazcheeseburger.jpg'/
> >
>
>
> Note the inclusion of the ETag header (as defined in "XEP-0150: Use of
> Entity Tags in XMPP Extensions") and the omission of a XEP-0300 hash
> element.
>
> If, for some reason the content-type and content-length headers can't be
> used for the  and  tags, then they can also be
> included as XEP-0131 headers (like the Etag).
>
> So, my proposal is that XEP-0385 be updated so that the XEP-0300 hash
> requirement gets relaxed to a SHOULD and that the inclusion of the Etag
> header be documented as an alternative in case a hash is not feasible.
> There might also be cases where neither a hash or an Etag header is
> available.
>
> I'd be happy to make the necessary changes and submit a pull request.
>
> Regards
> JC
>
>
>
>
>
>
>
>
> ___
> 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-0372 references pointing to different elements in same stanza

[Sergey Ilinykh]

I mean to use both *anchor* and *xml:lang* attributes to not write a
complicated element query parser if one is not provided by the used libs.

Best Regards,
Sergey


ср, 1 сент. 2021 г. в 11:10, JC Brand :

>
>
> On 01.09.21 10:06, Sergey Ilinykh wrote:
>
> why not just
>
> ```
>
> 
> ```
> ?
>
>
> Because that doesn't distinguish between elements with different names.
> Is that reference based on the  or  tag? Or perhaps a
>  tag?
>
> - JC
>
> ср, 1 сент. 2021 г. в 10:59, JC Brand :
>
>> Hi Jonas
>>
>> On 31.08.21 17:23, Jonas Schäfer wrote:
>>
>> Hi JC,
>>
>> This has somehow slipped past me.
>>
>>
>> Thanks for taking the time to respond.
>>
>> On Freitag, 13. August 2021 14:00:06 CEST JC Brand wrote:
>>
>> So, if you have a stanza with for example, both "subject" and "body"
>> tags, we can have references for both, and use the "anchor" attribute as
>> follows (I hope this comes out formatted properly once sent):
>>
>> > >
>>  Attention Bart Simpson
>>  Please hand in your homework before the end of the
>> day
>>  
>> 
>>
>> What about messages with multiple  elements disambiguated by xml:lang?
>> Could some conceivably contain a mention while others don't? Does this 
>> require
>> replicating the mention element all over? Same question for .
>>
>> This is another currently ambiguous and undefined use-case that I think
>> can be solved with my proposal.
>> As the XEP currently stands, there's no documented way to distinguish
>> between multiple  (or ) elements.
>>
>> Going with my proposal, the solution would be to have a separate
>>  element for each .
>> The mention parameters ("begin", "end") will be different for each
>>  since the mentioned text usually won't be in the exact same place
>> for the different translations.
>>
>> The "id" attribute can have any value, it doesn't have to be "body" or
>> "subject", those were just examples.
>>
>> Besides that, I don't think that adding an attribute to an element in this 
>> way
>> is really acceptable.
>>
>> I would prefer an approach which identifies the XML element without having to
>> modify the XML being referenced.
>>
>> The only mechanism that doesn't require modifying the referenced elements
>> that I can think of is XPath.
>>
>> My example then becomes:
>>
>> > >
>>  Attention Bart Simpson
>>  Aandag Bart Simpson
>>  Please hand in your homework before the end of the 
>> day
>>  Handig asseblief jou huiswerk in voor die einde van 
>> die dag
>>  > type="mention"/>
>>  > type="mention"/>
>>  
>>
>> Regards
>> JC
>>
>>
>> Libraries which currently represent body as a
>> (mappnig of language tags to) string(s) would now need extra magic in order 
>> to
>> be able to set ID attributes on those. This feels like a quite major change,
>> and not just to References, but to literally everything else.
>>
>> kind regards,
>> Jonas
>>
>>[1]: https://www.w3.org/TR/REC-xml/#id
>>
>>
>> ___
>> 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 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-0372 references pointing to different elements in same stanza

[Sergey Ilinykh]

why not just

```


```
?


Best Regards,
Sergey


ср, 1 сент. 2021 г. в 10:59, JC Brand :

> Hi Jonas
>
> On 31.08.21 17:23, Jonas Schäfer wrote:
>
> Hi JC,
>
> This has somehow slipped past me.
>
>
> Thanks for taking the time to respond.
>
> On Freitag, 13. August 2021 14:00:06 CEST JC Brand wrote:
>
> So, if you have a stanza with for example, both "subject" and "body"
> tags, we can have references for both, and use the "anchor" attribute as
> follows (I hope this comes out formatted properly once sent):
>
>  >
>  Attention Bart Simpson
>  Please hand in your homework before the end of the
> day
>  
> 
>
> What about messages with multiple  elements disambiguated by xml:lang?
> Could some conceivably contain a mention while others don't? Does this require
> replicating the mention element all over? Same question for .
>
> This is another currently ambiguous and undefined use-case that I think
> can be solved with my proposal.
> As the XEP currently stands, there's no documented way to distinguish
> between multiple  (or ) elements.
>
> Going with my proposal, the solution would be to have a separate
>  element for each .
> The mention parameters ("begin", "end") will be different for each 
> since the mentioned text usually won't be in the exact same place for the
> different translations.
>
> The "id" attribute can have any value, it doesn't have to be "body" or
> "subject", those were just examples.
>
> Besides that, I don't think that adding an attribute to an element in this way
> is really acceptable.
>
> I would prefer an approach which identifies the XML element without having to
> modify the XML being referenced.
>
> The only mechanism that doesn't require modifying the referenced elements
> that I can think of is XPath.
>
> My example then becomes:
>
>  >
>  Attention Bart Simpson
>  Aandag Bart Simpson
>  Please hand in your homework before the end of the 
> day
>  Handig asseblief jou huiswerk in voor die einde van 
> die dag
>   type="mention"/>
>   type="mention"/>
>  
>
> Regards
> JC
>
>
> Libraries which currently represent body as a
> (mappnig of language tags to) string(s) would now need extra magic in order to
> be able to set ID attributes on those. This feels like a quite major change,
> and not just to References, but to literally everything else.
>
> kind regards,
> Jonas
>
>[1]: https://www.w3.org/TR/REC-xml/#id
>
>
> ___
> 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-0371: Jingle ICE Transport Method - Question on ICE Restart detection

[Sergey Ilinykh]

> - the initiator consider the second message a response and maps it to an
> answer.
> - the responder will also consider it a response and map it to an answer.
>

Hi Philipp,

Why would it be considered as a response if there were no 
first?

PS when are you going to return to xsf@ chat? :-)
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0371: Jingle ICE Transport Method - Question on ICE Restart detection

[Sergey Ilinykh]

Hi Daniel,

If you didn't receive iq type=result yet for your offer then it looks like
a remote offer. maybe even something to consider for .

Best Regards,
Sergey


вт, 16 нояб. 2021 г. в 22:33, Daniel Gultsch :

> Hi,
>
> I’m trying to implement ICE Restarts with XEP-0371. The XEP states
> that ICE restarts can be detected by a changed ufrag and pwd
> attributes in the transport-info.
>
> However what I'm currently unclear about is how I can detect if the
> incoming transport-info is a request to restart ICE on its own or a
> response to an ICE restart we initiated.
>
> Or to put it into WebRTC terminology how do I know if a transport-info
> with changed ufrag/pwd is an Offer or an Answer.
>
> cheers
> Daniel
> ___
> 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
___