Re: [Standards] Council Minutes 2020-01-29

[Dave Cridland]

On Fri, 31 Jan 2020 at 22:46, Tedd Sterr  wrote:

> http://logs.xmpp.org/council/2020-01-29?p=h#2020-01-29-3fa75007a3268995
>
> *1) Roll Call*
> Present: Daniel, Zash, Jonas, Georg, Dave
>
> *2) Agenda Bashing*
> Jonas admits to having forgotten about the request for XEPs to LC/CFE -
> maybe one of those suggestions could be selected for advancement; and the
> Last Call on XEP-0363 expired yesterday, so that's something to vote on.
>
> *3a) Advance to Draft: XEP-0363 (HTTP File Upload)* -
> https://xmpp.org/extensions/xep-0363.html
> Daniel: +1
> Jonas: +1
> Zash: +1
> Georg: +1 (hate the XEP and the fact we're breaking out from XMPP into
> HTTP)
> Dave: [on-list] (expecting to +1)
>

+1, thanks to Daniel for addressing everything, and sorry this has been
such a slog.


>
> *3b-ish) We have a bunch of XEPs the community asked us to consider for
> advancement*
> Daniel thinks Bookmarks 2 (XEP-0402) is a good candidate - Jonas doesn't,
> but issuing a Last Call is probably a good idea.
>
> *3b) Last Call: XEP-0402 (Bookmarks 2 (This Time it's Serious))* -
> https://xmpp.org/extensions/xep-0402.html
> Jonas: +1
> Daniel: +1
> Zash: +1
> Georg: +1 (not sure it's old/mature enough yet)
> Dave: +1
>
> Daniel has three not-currently-in-production implementations, and so
> believes it to have some maturity. Georg recalls shortcomings regarding
> legacy compatibility - Daniel is confident about backward compatibility,
> though it might need to be better spelled out - Georg would welcome this.
>
> *4) Outstanding Votes*
> All done - good job, everyone!
>
> *5) Date of Next*
> 2020-02-05 1600 UTC
>
> *6) AOB*
> Jonas thinks it unfair that now there is plenty of time left, Georg is on
> a slow connection and probably doesn't want to bring up his eternal AOB.
> The tradition continues.
>
> Dave thanks Jonas for processing his recent heap of XEPs; and has an
> inbound patch for XEP-0431 (Full Text Search in MAM), since Matt and Kev
> argued that the beer requirement was an encumbrance; is aware there are
> many un-addressed comments and agreed changes piling up - should have these
> dealt with soon.
>
> Jonas thanks everyone for a complete meeting and 1.8 passed votes on
> Summit Travel Day; wishes everyone attending a nice summit, and will be
> attending remotely tomorrow, all being well.
>
> *7) Close*
> Jonas thanks everyone and wishes them safe travels.
>
> ___
> 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] OMEMO Update

[Dave Cridland]

Hi all,

So, first off, I was wrong. The summary is that the Signal Protocol (and
the IV values, in particular) is most likely not to be encumbered. While
it's not 100% clear, the balance of evidence is that a non-GPL
implementation that is fully compatible could be written.

A number of people had conversations with Matthew of Matrix over the past
weekend, and while I'll paraphrase what I think he said to me, I'd note
that others have slightly different interpretations, so please accept that
some details may differ - the essentials are the same, though.

1) Wire: It's not clear why the legal spat started between Wire and OWS,
but it seems that the position of OWS was that it was a line-by-line port,
and therefore a derivative work in the meaning of copyright.

2) Olm: Matthew has, via email, an assertion that OWS would not attempt any
legal action if the license were followed. While Matrix's implementation
does indeed change the IVs (Initialization Vectors; constants used to
"prime" the encryption), this was done partly out of an abundance of
caution, and partly because OWS indicated that Signal would never willingly
federate, lessening the need for interoperability. Olm has a proven
specification - people have implemented Olm from the specifications alone.
I now believe, therefore, that using the same IVs is probably safe legally.

Therefore, I propose:

a) OMEMO is fine as it is from a legal perspective.

b) OMEMO (and OMEMO 2) should reference Olm as the specification, and
simply provide the new IVs. While I would be more comfortable using Olm's
IVs, this is - like Matrix - out of an abundance of caution.

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

Re: [Standards] LAST CALL: XEP-0402 (Bookmarks 2 (This Time it's Serious))

[Maxime Buquet]

My answer is a mix of what Sam, Daniel, and lovetox say. :)


> This Last Call begins today and shall end at the close of business on
> 2020-02-12.

> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:

> 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?

Yes

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

I have not implemented it yet, but I would.

As this spec allows to handle bookmarks separately, it's easier to
handle group/Enterprise(tm) bookmarks. The server can return an
appropriate answer for a specific bookmark and not reject an update on
the whole list without any hint.

I also don't understand why the password field has been removed, same as
lovetox. While I might agree with a push towards using MUC member-only
rooms (I would think that's the intent?), I don't think we're there yet.
Password-MUCs are still a reality, and also still used in transports.

While a password field could be added to the XEP, I'm curious if
anything happened around the issue Link Mauve raised a few weeks ago
about allowing for a extensions in the XEP? This would avoid having to
rewrite an entire bookmark XEP everytime we think about a new feature.

> 4. Do you have any security concerns related to this specification?

As Daniel says, it would be good to mention PEP access_model in security
concerns.

> 5. Is the specification accurate and clearly written?

I agree with Sam in saying that the last part of the title is silly,
does not add any value, and makes it harder to cite. I like my XEPs dull
and straight to the point.


On Sunday, 30. January 2020 08:45:22 CET Daniel Gultsch wrote:
> Maybe the benefits of Bookmarks 2 over Bookmarks need to be spelled
> out more. Otherwise neither developers (as demonstrated by Phililpp)
> nor the approving body will know why they should use or accept this
> XEP.
> 
> The arguments for 402 I'm raising above are good; but I don’t want to
> personally tell them to every developer in order to convince them.
> That's the XEPs job.

I agree. (and jonas' answer in the thread looks closer to the intent of
the XEP already).

-- 
Maxime “pep” Buquet


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

Re: [Standards] LAST CALL: XEP-0402 (Bookmarks 2 (This Time it's Serious))

[Maxime Buquet]

On 2020/02/03, Maxime Buquet wrote:
> > 3. Do you plan to implement this specification in your code? If not,
> > why not?
> 
> I have not implemented it yet, but I would.
> 
> As this spec allows to handle bookmarks separately, it's easier to
> handle group/Enterprise(tm) bookmarks. The server can return an
> appropriate answer for a specific bookmark and not reject an update on
> the whole list without any hint.
> 
> I also don't understand why the password field has been removed, same as
> lovetox. While I might agree with a push towards using MUC member-only
> rooms (I would think that's the intent?), I don't think we're there yet.
> Password-MUCs are still a reality, and also still used in transports.
> 
> While a password field could be added to the XEP, I'm curious if
> anything happened around the issue Link Mauve raised a few weeks ago
> about allowing for a extensions in the XEP? This would avoid having to
> rewrite an entire bookmark XEP everytime we think about a new feature.

I forgot to add that the "autojoin" attribute is likely going to
conflict with 0430 Inbox' features. Which one should I respect if I
implement both XEPs?

As Dave authored both it might be interesting to sync up on that.

-- 
Maxime “pep” Buquet


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

Re: [Standards] LAST CALL: XEP-0402 (Bookmarks 2 (This Time it's Serious))

[Dave Cridland]

Very quick note: I've picked up an entertaining virus while at FOSDEM -
hopefully not *that* coronavirus - so I'm not thinking clear enough to
respond to the comments here but I am reading them.

At the moment, I don't think there's anything I find myself moved to argue
against; Maxime's point about autojoin is interesting but I'm not entirely
sure that Inbox works (well) with '45 at all at the moment.

Dave.

On Wed, 29 Jan 2020 at 16:33, Jonas Schäfer  wrote:

> This message constitutes notice of a Last Call for comments on
> XEP-0402.
>
> Title: Bookmarks 2 (This Time it's Serious)
> Abstract:
> This specification defines a syntax and storage profile for keeping a
> list of chatroom bookmarks on the server.
>
> URL: https://xmpp.org/extensions/xep-0402.html
>
> This Last Call begins today and shall end at the close of business on
> 2020-02-12.
>
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
>
> 2. Does the specification solve the problem stated in the introduction
> and requirements?
>
> 3. Do you plan to implement this specification in your code? If not,
> why not?
>
> 4. Do you have any security concerns related to this specification?
>
> 5. Is the specification accurate and clearly written?
>
> Your feedback is appreciated!
> ___
> 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] NEW: XEP-0430 (Inbox)

[Florian Schmaus]

On 29.01.20 15:21, Jonas Schäfer (XSF Editor) wrote:
> Version 0.1.0 of XEP-0430 (Inbox) has been released.
> 
> Abstract:
> This specification proposes a mechanism by which clients can find a
> list of ongoing conversations and their state.
> 
> Changelog:
> Accepted by vote of Council on 2020-01-22. (XEP Editor (jsc))
> 
> URL: https://xmpp.org/extensions/xep-0430.html

After re-reading this inbox xep I was surprised to find that there
appears to be no indication how to determine which conversation has the
most recent unread message(s). I think we either need a timestamp in the
forwarded messages or define that the messages of the forwarded
conversations are in order from most recent to most oldest, or
potentially do both.

Some (most?) modern GUIs display conversations ordered by the most
recent activity (the actual number of unread messages is sometimes even
not displayed). Hence that information would be very helpful to some
clients.


Unrelated to the above: I think I like that the initial IQ request does
not, unlike MAM, have an additional query ID. Instead this appears to
use the IQ id as query id. Nifty (and probably something we want to
remember if we ever do a MAM namespace bump).

- Florian



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

Re: [Standards] LAST CALL: XEP-0402 (Bookmarks 2 (This Time it's Serious))

[Florian Schmaus]

On 03.02.20 18:34, Dave Cridland wrote:
> Very quick note: I've picked up an entertaining virus while at FOSDEM -
> hopefully not *that* coronavirus - so I'm not thinking clear enough to
> respond to the comments here but I am reading them.
> 
> At the moment, I don't think there's anything I find myself moved to
> argue against; Maxime's point about autojoin is interesting but I'm not
> entirely sure that Inbox works (well) with '45 at all at the moment.

I've questioned in a previous mail if inbox is the right venue for such
a thing. I actually tend to believe that information regarding the
currently open conversations (and probably their order, which is
nice-to-have for TUI clients) belongs not into inbox but in bookmarks.
This means that we do not view XMPP bookmarks as MUC (xep45) specific,
but to be generic to contain any sort of conversation bookmark (MUC,
1:1, MIX, Muc-light, MUC-sub, …).

- Florian

> On Wed, 29 Jan 2020 at 16:33, Jonas Schäfer  > wrote:
> 
> This message constitutes notice of a Last Call for comments on
> XEP-0402.
> 
> Title: Bookmarks 2 (This Time it's Serious)
> Abstract:
> This specification defines a syntax and storage profile for keeping a
> list of chatroom bookmarks on the server.
> 
> URL: https://xmpp.org/extensions/xep-0402.html
> 
> This Last Call begins today and shall end at the close of business on
> 2020-02-12.
> 
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org 
> discussion list:
> 
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
> 
> 2. Does the specification solve the problem stated in the introduction
> and requirements?
> 
> 3. Do you plan to implement this specification in your code? If not,
> why not?
> 
> 4. Do you have any security concerns related to this specification?
> 
> 5. Is the specification accurate and clearly written?
> 
> Your feedback is appreciated!
> ___
> 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
> ___
> 




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