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

[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



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

Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2019

[Holger Weiß]

* ??? ??  [2019-01-14 14:16]:
> > If you don't do this, read markers will sometimes work and sometimes
> > not.  You'd accept this UX breakage in order to save the server operator
> > some disk space?
> 
> Problem is not inefficient disk space utilization. Problem is that
> instead of developing a proper solution, this ad-hoc approach is
> presented like normal practice.

Ok, I agree it's inefficient.  So it's just about the question whether
workarounds prevent development of proper solutions, which is a moot
discussion I guess.

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

Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2019

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

> If you don't do this, read markers will sometimes work and sometimes
> not.  You'd accept this UX breakage in order to save the server operator
> some disk space?

Problem is not inefficient disk space utilization. Problem is that
instead of developing a proper solution, this ad-hoc approach is
presented like normal practice.

But since you mention it, when clients receives a lot of duds instead
of real messages from an archive, it's a problem,  because it
noticeably slows fetching data.
Of course, this is far from being the biggest problem with XMPP.


-- 
Ненахов Андрей
Директор ООО "Редсолюшн" (Челябинск)
(351) 750-50-04
http://www.redsolution.ru
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2019

[Holger Weiß]

* ??? ??  [2018-12-25 00:32]:
> Actually biggest issue are offline clients. Some developers even spam
> message archive with empty messages to 'mark' previous messages as read.
> Not a good idea.

If you don't do this, read markers will sometimes work and sometimes
not.  You'd accept this UX breakage in order to save the server operator
some disk space?

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

Re: [Standards] XMPP Council Minutes 2018-12-19

[Kevin Smith]

On 13 Jan 2019, at 11:29, Jonas Schäfer  wrote:
> 
> On Dienstag, 25. Dezember 2018 17:43:28 CET Kevin Smith wrote:
>>> On 20 Dec 2018, at 20:27, Tedd Sterr  wrote:
>>> Dave noticed that Jonas pushed through XEP-0412 (XMPP Compliance Suites
>>> 2019) before all votes have been made, and has literally no idea what do
>>> to about it as there is no process to handle a process violation. Jonas
>>> suggests reverting the changes in Git; Georg suggests pretending it never
>>> happened unless the final vote contradicts, and revert if so. Dave thinks
>>> reverting would be a bad idea as it could lead to 0412 referring to a
>>> different XEP.
>> I don’t really want to be the blocker of progress, but there are various
>> things in here that I’m not convinced by. 
> 
> Sorry for putting the pressure on you by delaying the suites for such long 
> time, even though I did not intend to do so.
> 
>> Some of them (368) were existing
>> things that I don’t feel are really essential in a core client/server
> 
> Noted and fixed.
> 
>> , or
>> are inconsistent (84 but not 163 in a server), 
> 
> Noted and fixed.
> 
>> others are new (what does it
>> mean for 184 to be supported by a server? 
> 
> That was simply a typo, thanks for pointing it out.
> 
>> 398 is neat, but does it deserve
>> to be in a compliance suite already?). 
> 
> Yes, I think so. It provides valuable support in moving the ecosystem forward.
> 
>> I’m also not sure that 7622 is
>> actually practically required for interop, as opposed to 6122, and a note
>> to that effect would be sane.
> 
> Changed.
> 
> (The actual change isn’t published yet, but it only hinges on the docker 
> build.)

Thanks. +1 based on the changes described above.

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