Re: [Standards] LAST CALL: XEP-0410 (MUC Self-Ping (Schrödinger's Chat))

2019-01-15 Thread Georg Lukas 
Hi Daniel,

thanks very much for your feedback. I'd like to improve the XEP text to
make the points clearer to understand.

* Daniel Gultsch  [2019-01-08 18:31]:
> I’m not sure. Is the intent of the XEP to keep me reliably connected
> to a MUC or is it intended to figure out if I’m connected to a group
> chat?

It's the latter. I've reviewed the abstract and the intro section, and I
have the feeling that they both made this point rather clear. While I
understand there is a need to solve the former problem, it's not the
focus of this XEP. Do you have a wording suggestion for reducing the
confusion? Should I add a sentence along the lines of

| This extension can not ensure that a client remains reliably
| connected, merely detect a disconnect.


> If the intent of the protocol is to keep me connected to a MUC I’m
> missing on on very crucial information like:
> * How often do I ping?
> * What time out do I use?

These two are highly dependent on the kind of data connection you have,
and it's hard to provide generic guidelines. In my implementation, I
have both set to 15 minutes, but I can see an argument for higher as
well as lower values. A sane combo for a mobile client would be
45min/2min as well, whereas a stationary desktop client could get along
with 5min/30s. Should I add an indication of those possibilities into
the XEP text?

> * Does the time out increase when i’m in smack hibernation?

When you are in hibernation, you shouldn't send any time-critical
packets at all. If you do, you should probably base the timeout not on
when you generate the stanza, but when it's actually sent after the
resumption.

To me this feels like obvious from how 0198 works, but I can add a
sentence about that to the Business Rules.

> * What do I do when i notice I’m no longer connected?

This is adressed in §3.2:

| - Any other error: the client is probably not joined.
| - Timeout (no response): the MUC service (or another client) is
|   unreachable. The client may indicate the status to the user and
|   re-attempt the self-ping after some timeout, until it receives
|   either an error or a success response.

From your remark I suppose I should change the first one into "... and
should perform a re-join.". Is there anything else that needs to be
clarified?

> * Do I try to reconnect? How many times? In what interval? Is there a
> maximum number of retries?

Like with the timeout question above, this is highly dependent on your
implementation. My implementation attempts to rejoin every 15mins, as
part of the periodic self-ping check timer. I considered that as a good
trade-off between battery consumption, responsiveness to the user and
probability of still having enough MUC history to not miss anything.

> * Do i still ping the group chat even if my app is in background or in
> Push-Hibernation?
> * Do I need a push from the server in #ping-interval to wake up my app
> to allow it to ping the muc server?

The interaction with Push is a very interesting area that I haven't had
the need to cover yet. While you are in hibernation, you obviously can't
ping any MUCs, so the first moment you can do it is after you are
woken up. From a workaround-for-the-workaround perspective, it makes
some sense to have a periodic wake-up that is triggered after you
haven't been woken up for a certain time (1hr? 2hr? 24hr?), which will
tell the client to perform a round of MUC pings.

But if we look into the big picture, it would make much more sense to
allow Push support on the MUC component, implement it in all servers,
deploy it everywhere and then to get woken up by the MUC if you aren't a
participant any more and "important" traffic is sent. But this is
something for XEP-0357.

> I’m unsure what problem it aims to solve so I can’t judge if it solves
> that problem.

I could imagine it is one of those, or maybe even all of them:

- https://github.com/siacs/Conversations/issues/1671
- https://github.com/siacs/Conversations/issues/2690
- https://github.com/siacs/Conversations/issues/2983


Kind regards,


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
___

Re: [Standards] Confusing Language in XEP-0261 (Jingle In-Band Bytestreams Transport Method)

2019-01-15 Thread Guus der Kinderen 
Hi Larry,

I don't think that this mailinglist is the right place to discuss your
questions.

Although I'm not familiar with your issue, I think you should address them
at Google, not the XMPP standards mailinglist. I suggest that you start at
https://support.google.com/ and see where that gets you.

Regards,

  Guus

On Tue, 15 Jan 2019 at 13:17, larry martz  wrote:

> I have a couple questions... While looking into my Google account after a
> factory reset I was asked to choose what phone I Wanted to restore. But my
> options were exactly the same. In addition Google didn't recognize my phone
> number, I had changed my password the week before but the old one was the
> one I had to use.
> And çan someone explain the G-suite, and how that site can be a administor
> to numerous devices at one time. Last how can I not allow that type of an
> administrator.tnx
>
> On Mon, Jan 14, 2019, 11:49 AM Peter Saint-Andre  wrote:
>
>> On 1/12/19 1:01 PM, Jonas Schäfer wrote:
>> > On Montag, 17. Dezember 2018 16:50:17 CET Sebastian Riese wrote:
>> >> XEP-0261  uses "bytestream"
>> >> for the overall Jingle session and "session" for the IBB session (at
>> >> least it does so consistently). This is *extremely* confusing. For
>> >>
>> >> example section 2.5 reads:
>> >>> Whenever a party is finished with a particular session within the
>> >>
>> >> bytestream, it SHOULD send an IBB  as shown above. This applies
>> >> to all sessions, including the last one.
>> >>
>> >>> To close the bytestream itself (e.g., because the parties have
>> >>
>> >> finished using all sessions associated with the bytestream), a party
>> >> sends a Jingle session-terminate action as defined in XEP-0166.
>> >>
>> >> This nomenclature is just wrong: The Jingle session manages multiple
>> >> In-Band Bytestream sessions. If you close the Jingle session there may
>> >> be zero or more bytestream sessions that are closed (and perhaps other
>> >> transport sessions – Jingle does not prescribe uniform transports in a
>> >> session).
>> >>
>> >> If you all agree I would make a PR to fix this issue. My proposal is to
>> >> use "session" for Jingle sessions and "bytestream" for IBB sessions, if
>> >> this is deemed to be too confusing also, I could spell out "Jingle
>> >> session" and "IBB session".
>> >
>> > I suggest you take the silence as agreement.
>>
>> WFM
>>
>> ___
>> 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] Confusing Language in XEP-0261 (Jingle In-Band Bytestreams Transport Method)

2019-01-15 Thread larry martz 
I have a couple questions... While looking into my Google account after a
factory reset I was asked to choose what phone I Wanted to restore. But my
options were exactly the same. In addition Google didn't recognize my phone
number, I had changed my password the week before but the old one was the
one I had to use.
And çan someone explain the G-suite, and how that site can be a administor
to numerous devices at one time. Last how can I not allow that type of an
administrator.tnx

On Mon, Jan 14, 2019, 11:49 AM Peter Saint-Andre  On 1/12/19 1:01 PM, Jonas Schäfer wrote:
> > On Montag, 17. Dezember 2018 16:50:17 CET Sebastian Riese wrote:
> >> XEP-0261  uses "bytestream"
> >> for the overall Jingle session and "session" for the IBB session (at
> >> least it does so consistently). This is *extremely* confusing. For
> >>
> >> example section 2.5 reads:
> >>> Whenever a party is finished with a particular session within the
> >>
> >> bytestream, it SHOULD send an IBB  as shown above. This applies
> >> to all sessions, including the last one.
> >>
> >>> To close the bytestream itself (e.g., because the parties have
> >>
> >> finished using all sessions associated with the bytestream), a party
> >> sends a Jingle session-terminate action as defined in XEP-0166.
> >>
> >> This nomenclature is just wrong: The Jingle session manages multiple
> >> In-Band Bytestream sessions. If you close the Jingle session there may
> >> be zero or more bytestream sessions that are closed (and perhaps other
> >> transport sessions – Jingle does not prescribe uniform transports in a
> >> session).
> >>
> >> If you all agree I would make a PR to fix this issue. My proposal is to
> >> use "session" for Jingle sessions and "bytestream" for IBB sessions, if
> >> this is deemed to be too confusing also, I could spell out "Jingle
> >> session" and "IBB session".
> >
> > I suggest you take the silence as agreement.
>
> WFM
>
> ___
> 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
___