Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

[Ruslan Marchenko]

Hi,

Am 29.08.2019 um 13:24 schrieb Andrew Nenakhov:
I might be late to the party. This email was sent by me on August 03 
after changing my email address and resubscribing to this list, but it 
seems that I wasn't put through. My points against XEP-0353 in current 
form still stand. I obviously missed all conversations here in August, 
so I might need to catch up on this though.


сб, 3 авг. 2019 г. в 21:04, Andrew Nenakhov 
>:


вт, 30 июл. 2019 г. в 23:42, Jonas Schäfer mailto:jo...@wielicki.name>>:

1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?


Yes.


2. Does the specification solve the problem stated in the
introduction
and requirements?


Partially. This specification is not suitable to work with clients
that rely on push notifications and fetching messages from an archive.

3. Do you plan to implement this specification in your code?
If not,
why not?


We have implemented this specification on iOS client, and
discovered that it is unsuitable in real life scenarios. We have
updated it with additional callback routine, the changes and
stanza format is described here:

https://docs.google.com/document/d/1geR2-VlKkjwqFftstV7O1cYfGqKQy-eEUepgRrge0ow/edit

This modified solution does the job. We have also created a test
bot for testing automated VoIP calling, bot's address is
dev...@dev.xabber.com  (calling bot
works well, receiving calls from bot has some bugs at the moment).
One may perform calls using preview version
 of Xabber
for iOS (it's under construction at the moment and has quite a
number of bugs, but VoIP is mostly working by now).




Looking at documents one additional obstacle pops up to my eye in 
regards to relying on MAM. XEP-0313 states at 5.1.1


   At a minimum, the server MUST store the  elements of a stanza. 
It is suggested that other elements that are used in a given deployment 
to supplement conversations (e.g. XHTML-IM payloads) are also stored. 
Other elements MAY be stored.


The implementation I did for instance is using this allowance and 
storing only  element with metadata (to minimize storage) hence 
won't fly in this particular example (MAM would retrieve only "Voice 
Call" message).



Regards,

Ruslan

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

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

[Jonas Schäfer]

Comments below.

On Donnerstag, 29. August 2019 13:24:34 CEST Andrew Nenakhov wrote:
> I might be late to the party. This email was sent by me on August 03 after
> changing my email address and resubscribing to this list, but it seems that
> I wasn't put through. My points against XEP-0353 in current form still
> stand. I obviously missed all conversations here in August, so I might need
> to catch up on this though.

Lucky for you, there has been no discussion.

> 
> сб, 3 авг. 2019 г. в 21:04, Andrew Nenakhov  > вт, 30 июл. 2019 г. в 23:42, Jonas Schäfer :
> >> 1. Is this specification needed to fill gaps in the XMPP protocol
> >> stack or to clarify an existing protocol?
> > 
> > Yes.
> > 
> >> 2. Does the specification solve the problem stated in the introduction
> >> and requirements?
> > 
> > Partially. This specification is not suitable to work with clients that
> > rely on push notifications and fetching messages from an archive.
> > 
> > 3. Do you plan to implement this specification in your code? If not,
> > 
> >> why not?
> > 
> > We have implemented this specification on iOS client, and discovered that
> > it is unsuitable in real life scenarios. We have updated it with
> > additional
> > callback routine, the changes and stanza format is described here:
> > 
> > https://docs.google.com/document/d/1geR2-VlKkjwqFftstV7O1cYfGqKQy-eEUepgRr
> > ge0ow/edit
> > 
> > This modified solution does the job. We have also created a test bot for
> > testing automated VoIP calling, bot's address is dev...@dev.xabber.com
> > (calling bot works well, receiving calls from bot has some bugs at the
> > moment). One may perform calls using preview version
> >  of Xabber for
> > iOS (it's under construction at the moment and has quite a number of bugs,
> > but VoIP is mostly working by now).

Thanks for posting this.

Can someone of the Jingle folks please review and comment on this? From my 
perspective, it looks very reasonable to have a callback mechanism to test if 
a session still exists before proceeding to show the call interface.

Ideally, Andrew, you would make a PR against the xeps repository [1]. I am not 
sure if you are familiar with the process. If you are not, you can reach out 
to me off-list and I’ll get you started. In any case, we’d need a confirmation 
that it is okay for you and the company behind Xabber to integrate this change 
into XEP-0353, copyright and IPR wise [2].

kind regards,
Jonas

   [1]: https://github.com/xsf/xeps/
   [2]: https://xmpp.org/about/xsf/ipr-policy.html

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

[Andrew Nenakhov]

I might be late to the party. This email was sent by me on August 03 after
changing my email address and resubscribing to this list, but it seems that
I wasn't put through. My points against XEP-0353 in current form still
stand. I obviously missed all conversations here in August, so I might need
to catch up on this though.

сб, 3 авг. 2019 г. в 21:04, Andrew Nenakhov :

> вт, 30 июл. 2019 г. в 23:42, Jonas Schäfer :
>
>> 1. Is this specification needed to fill gaps in the XMPP protocol
>> stack or to clarify an existing protocol?
>>
>
> Yes.
>
>
>>
>> 2. Does the specification solve the problem stated in the introduction
>> and requirements?
>>
>
> Partially. This specification is not suitable to work with clients that
> rely on push notifications and fetching messages from an archive.
>
> 3. Do you plan to implement this specification in your code? If not,
>> why not?
>>
>
> We have implemented this specification on iOS client, and discovered that
> it is unsuitable in real life scenarios. We have updated it with additional
> callback routine, the changes and stanza format is described here:
>
> https://docs.google.com/document/d/1geR2-VlKkjwqFftstV7O1cYfGqKQy-eEUepgRrge0ow/edit
>
> This modified solution does the job. We have also created a test bot for
> testing automated VoIP calling, bot's address is dev...@dev.xabber.com
> (calling bot works well, receiving calls from bot has some bugs at the
> moment). One may perform calls using preview version
>  of Xabber for
> iOS (it's under construction at the moment and has quite a number of bugs,
> but VoIP is mostly working by now).
>
> 4. Do you have any security concerns related to this specification?
>>
>
> Yes. Security considerations does not cover the issue of private
> information exposure (IP address) to remote party when taking part in a
> jingle session. This is covered in XEP-0166 Security Considerations though,
> but I think it should make sense that taking part in jingle session not
> only results in a presence leak, but also in disclosure of IP.
>
> 5. Is the specification accurate and clearly written?
>>
>
> Quite clearly.
>
>
-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Byte count of XEP-0084: User Avatar image data

[Dave Cridland]

On Wed, 28 Aug 2019 at 16:21, Paul Schaub  wrote:

> Hi Standardists!
>
> I noticed, that XEP-0084 was update in version 1.1.2 to allow image
> "height"s and "width"s up to 65536 (previously 256). While I agree, that
> this is a sensible up to date range for width and height, I think that
> the range of the size attribute (bytes) would need to be updated as well.
>
> As of today, the XML Schema for the metadata namespace states the
> datatype of bytes to be unsigned short, which is at maximum 65536. 65536
> bytes will probably quickly be exhausted for images bigger than 256x256).
>
> Interestingly, example 10 in the XEP already features an  with a
> bytes value of 78912, which exceeds the limits of unsignedShort.
>
> I'd propose to bump the datatype of bytes up to unsignedInteger, which
> should be sufficient for now.
>
>
That sounds good.


> Do you think this would require a namespace bump?
>
>
Given the example (which, IMO, holds more weight than the schema in our
world), no.


> Related PR: https://github.com/xsf/xeps/pull/812
>
> Happy Hacking!
> Paul
> ___
> 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] LAST CALL: XEP-0353 (Jingle Message Initiation)

[Dave Cridland]

On Thu, 29 Aug 2019 at 09:09, Daniel Gultsch  wrote:

> Am Di., 30. Juli 2019 um 18:42 Uhr schrieb Jonas Schäfer <
> jo...@wielicki.name>:
> > 1. Is this specification needed to fill gaps in the XMPP protocol
> > stack or to clarify an existing protocol?
>
> Yes
>
> > 2. Does the specification solve the problem stated in the introduction
> > and requirements?
>
> I don’t know yet. I haven’t implemented it.
>
> > 3. Do you plan to implement this specification in your code? If not,
> > why not?
>
> I do have plans to implement this (hopefully by the end of this year~ish)
>
> Given the low number of implementations I would suggest to wait a
> little longer until we have more experience.
>

I was under the impression that there were a few implementations of this
around, actually - anyone care to chime in? Fippo, perhaps, or Андрей?

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

Re: [Standards] Council Voting Summary 2019-08-06

[Dave Cridland]

Kev,

Can I persuade you to work on this on the road to Draft, rather than
leaving a ProtoXEP addressing a problem I think we all want to solve
languishing in limbo?

Dave.

On Thu, 29 Aug 2019 at 09:22, Kevin Smith  wrote:

>
>
> > On 29 Aug 2019, at 09:19, Daniel Gultsch  wrote:
> >
> > Hi,
> >
> > Am Mi., 7. Aug. 2019 um 16:18 Uhr schrieb Tedd Sterr <
> teddst...@outlook.com>:
> >
> >> VETOED (-1:0:+4)
> >> Proposed XMPP Extension: Message Reactions -
> https://xmpp.org/extensions/inbox/reactions.html
> >> Dave: +1 (enthusiastic about the problem space, but expect this will
> need a lot of changes on the way to Draft)
> >> Georg: +1 (it is good enough for Experimental)
> >> Jonas: +1 (details can be ironed out)
> >> Kev: -1 (we need a general way of referencing a previous message for
> assorted things and to use that everywhere, while the reactions syntax is
> not reusable)
> >> Link: +1 (issues can be ironed out before Draft)
> >
> >
> > just a quick 'imho' from my point of view here.
> > I get where this veto is coming from. We discussed the need to
> > collapse meta data around a message within the archive and I totally
> > agree that long term we need to solve this.
> > However I find it unfair to put the burden of figuring out a solution
> > to a very complex problem upon a single XEP (or its authors).
>
> Which is why I offered to the authors to fix this now so the XEP could be
> accepted, as I had some spare cycles at the time, but that offer wasn’t
> taken up. I very much want a reactions XEP published, and was willing to
> put the time in to make it happen.
>
> /K
>
> ___
> 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] Council Voting Summary 2019-08-06

[Kevin Smith]

> On 29 Aug 2019, at 09:19, Daniel Gultsch  wrote:
> 
> Hi,
> 
> Am Mi., 7. Aug. 2019 um 16:18 Uhr schrieb Tedd Sterr :
> 
>> VETOED (-1:0:+4)
>> Proposed XMPP Extension: Message Reactions - 
>> https://xmpp.org/extensions/inbox/reactions.html
>> Dave: +1 (enthusiastic about the problem space, but expect this will need a 
>> lot of changes on the way to Draft)
>> Georg: +1 (it is good enough for Experimental)
>> Jonas: +1 (details can be ironed out)
>> Kev: -1 (we need a general way of referencing a previous message for 
>> assorted things and to use that everywhere, while the reactions syntax is 
>> not reusable)
>> Link: +1 (issues can be ironed out before Draft)
> 
> 
> just a quick 'imho' from my point of view here.
> I get where this veto is coming from. We discussed the need to
> collapse meta data around a message within the archive and I totally
> agree that long term we need to solve this.
> However I find it unfair to put the burden of figuring out a solution
> to a very complex problem upon a single XEP (or its authors). 

Which is why I offered to the authors to fix this now so the XEP could be 
accepted, as I had some spare cycles at the time, but that offer wasn’t taken 
up. I very much want a reactions XEP published, and was willing to put the time 
in to make it happen.

/K

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

Re: [Standards] Council Voting Summary 2019-08-06

[Daniel Gultsch]

Hi,

Am Mi., 7. Aug. 2019 um 16:18 Uhr schrieb Tedd Sterr :

> VETOED (-1:0:+4)
> Proposed XMPP Extension: Message Reactions - 
> https://xmpp.org/extensions/inbox/reactions.html
> Dave: +1 (enthusiastic about the problem space, but expect this will need a 
> lot of changes on the way to Draft)
> Georg: +1 (it is good enough for Experimental)
> Jonas: +1 (details can be ironed out)
> Kev: -1 (we need a general way of referencing a previous message for assorted 
> things and to use that everywhere, while the reactions syntax is not reusable)
> Link: +1 (issues can be ironed out before Draft)


just a quick 'imho' from my point of view here.
I get where this veto is coming from. We discussed the need to
collapse meta data around a message within the archive and I totally
agree that long term we need to solve this.
However I find it unfair to put the burden of figuring out a solution
to a very complex problem upon a single XEP (or its authors). Vaguely
pointing to to Message ~References~ Attaching isn’t very helpful
either IMHO as it is not proven to me that this XEP will actually
solve the problem. Furthermore if we ever do collapsing we need to
deal with legacy anyway that is not using the generalized mechanism
(Display markers, delivery receipts, Corrections) adding one more to
that list doesn’t feel like a big deal to me.

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

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

[Daniel Gultsch]

Am Di., 30. Juli 2019 um 18:42 Uhr schrieb Jonas Schäfer :
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?

Yes

> 2. Does the specification solve the problem stated in the introduction
> and requirements?

I don’t know yet. I haven’t implemented it.

> 3. Do you plan to implement this specification in your code? If not,
> why not?

I do have plans to implement this (hopefully by the end of this year~ish)

Given the low number of implementations I would suggest to wait a
little longer until we have more experience.

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