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

[Maxime Buquet]

On 2020/02/13, Florian Schmaus wrote:
> On 1/29/20 5:33 PM, Jonas Schäfer (XSF Editor) 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.
> 
> Besides my feedback regarding arbitrary extensions being added by the
> client and/or the server, I believe it is a missed opportunity that this
> XEP is MUC specific.
> 
> Instead it should be able to also deal with 1:1 chats, MIXes, MucSub,
> MUC-light, and all future (group)chat protocols. This also means we no
> longer have to discuss if we put MIXes into the roster, instead the
> user's server could just inject the joined MIXes into this. The Inbox
> XEP would then just provide mechanism to deliver the unread count and
> timestamp of unread conversations (potentially linking to the related
> bookmark2 node).
> 
> So ultimately this should not be Bookmarks 2, but Roster 2, based on
> PubSub [1].

I like the idea

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

On Thu, 13 Feb 2020 at 20:14, Florian Schmaus  wrote:

> On 1/29/20 5:33 PM, Jonas Schäfer (XSF Editor) 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.
>
> Besides my feedback regarding arbitrary extensions being added by the
> client and/or the server, I believe it is a missed opportunity that this
> XEP is MUC specific.
>
>
I'm not entirely convinced it is, or ever was; in any case I have a PR open
that makes it clear that it's a jid for a group chat of some kind, and not
necessarily XEP-0045:

https://github.com/xsf/xeps/pull/892/files#diff-04bb1eb88bb1740e9f3d97e395c890efR101

So ultimately this should not be Bookmarks 2, but Roster 2, based on
> PubSub [1].
>

I sort of think we could review roster, but last time I attempted that
there was a lot of push-back.

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

[Florian Schmaus]

On 1/29/20 5:33 PM, Jonas Schäfer (XSF Editor) 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.

Besides my feedback regarding arbitrary extensions being added by the
client and/or the server, I believe it is a missed opportunity that this
XEP is MUC specific.

Instead it should be able to also deal with 1:1 chats, MIXes, MucSub,
MUC-light, and all future (group)chat protocols. This also means we no
longer have to discuss if we put MIXes into the roster, instead the
user's server could just inject the joined MIXes into this. The Inbox
XEP would then just provide mechanism to deliver the unread count and
timestamp of unread conversations (potentially linking to the related
bookmark2 node).

So ultimately this should not be Bookmarks 2, but Roster 2, based on
PubSub [1].

- Florian

1: One not-required but missing optional feature to achieve feature
parity with the roster would be a roster versioning equivalent for
PubSub nodes, i.e. NodeVer. But something like that should not be to
hard to specify and is beneficial for other use cases too.
___
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 2/13/20 8:31 PM, Dave Cridland wrote:
> On Wed, 12 Feb 2020 at 16:54, Georg Lukas  > wrote:
> Persistence: certain PEP implementations from the past, which are still
> distributed by major OS platforms, chose to implement PEP in a
> non-persistent way, only keeping data in RAM. I know we are deep in
> implementation-defined behavior territory here, but a warning to
> developers might be appropriate.
> 
> 
> No idea what to say here. Feels like "Clients are RECOMMENDED to use
> servers which are not totally shit".

I wonder if the right conclusion to draw here, may be that we need a
feature announcement if the PubSub/PEP service will persist nodes or not
(and how many items?).

In the past, some PubSub/PEP implementations where bootstraped without
persistence support, likely because it is easier to get a pure in-memory
implementation done first. And it is probably safe to assume this will
also happen with some new implementations in the future. Mind that some
PubSub/PEP use-cases are perfectly fine without item persistence.

Hence why not add such a feature [1] and have XEPs like xep402 require
clients to check for the existence of this feature?

- Florian

1: Probably to xep60?


___
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]

Georg,

On Wed, 12 Feb 2020 at 16:54, Georg Lukas  wrote:

> * Jonas Schäfer  [2020-01-29 17:34]:
> > 1. Is this specification needed to fill gaps in the XMPP protocol
> > stack or to clarify an existing protocol?
>
> Yes, it's a significant improvement over existing bookmarks.
>
> > 2. Does the specification solve the problem stated in the introduction
> > and requirements?
>
> Yes, mostly (see below).
>
> > 3. Do you plan to implement this specification in your code? If not,
> > why not?
>
> Yes.
>
> > 4. Do you have any security concerns related to this specification?
>
> As stated before, the publish-options need a very prominent mention.
>
> > 5. Is the specification accurate and clearly written?
>
> As was written before, the password should be re-added for backward
> compatibility.
>
> Furthermore, I'm missing the following things:
>
>
> RECOMMENDED name attribute: in past bookmark specifications, this
> has led to clients or servers filling the `name` field with the
> localpart of the room JID, which made it impossible for the receiving
> client to determine whether this is a user-configured name that just
> randomly happens to be equal to the localpart, or if it is the "default"
> value and the client rather should display the disco#info name of the
> room. Please make the name OPTIONAL instead, and add clear advise to
> developers that it shall only be populated by the user, not
> automatically.
>
>
>
Done.


>  element: please add implementation notes that a client should
> only populate this element if the nickname is different from the
> XEP-0172/PEP value, and that when receiving a bookmark without the
> nickname, the client SHOULD fall back to the XEP-0172/PEP value.
>
>
Done.


>
> Persistence: certain PEP implementations from the past, which are still
> distributed by major OS platforms, chose to implement PEP in a
> non-persistent way, only keeping data in RAM. I know we are deep in
> implementation-defined behavior territory here, but a warning to
> developers might be appropriate.
>
>
No idea what to say here. Feels like "Clients are RECOMMENDED to use
servers which are not totally shit".


>
> Backward compatibility:
>
> First, the wording in the Compatibility section is not very clear:
>
> | A server MAY choose to unify the bookmarks from both Private XML
> | Storage (XEP-0049) [2] based and the current Bookmark Storage (XEP-0048)
> | [1].
>
> Does that mean that Private XML will be merged into PEP-Bookmarks, but
> neither into Bookmarks2? Or is that related to the following statement?
> Or the multiple following statements?
>
>
"from both" suggests "to this" as well. But "text welcome".


> Second, I'd like to see better hints to client developers regarding how
> to make use of the different server-side capability scenarios.
>
> on a server that doesn't support PEP/publish-options: use 0049
>
> on a server that supports urn:xmpp:bookmarks:0#compat*: use 0402
>
> on a server that just supports 0049 and PEP: ???
>
> I wanted to suggest that a server implementing 0402 must mandatorily
> implement both compat mechanisms, but it looks like 0402 doesn't have a
> feature var and doesn't depend on explicit server support anyway, so
> this point would be moot. However, I'm not sure how to best proceed from
> here.
>

Me neither - as before, "text welcome".


>
>
> Georg
> ___
> 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-0402 (Bookmarks 2 (This Time it's Serious))

[Dave Cridland]

These are late Last Call comments, but seeing as I'm an author *and* on the
Council, I figured better late than never...

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?
>
>
Yes; in as much as bookmarks are a bit broken and this is a cleaner design
(and one we have discussed for years prior to this).


> 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'm not entirely sure that any bookmarks are, currently, relevant for my
work.


> 4. Do you have any security concerns related to this specification?
>
>
Re-adding the password means that MUC passwords are back, but that's a
reasonable compromise.


> 5. Is the specification accurate and clearly written?
>
>
While trying to apply the changes others have suggested, I noted that it
says that if autojoin is set to true on a notification of a change, a
client should join the chatroom - this seems reasonable - but if it's set
to false, a client should immediately leave. This latter seems unexpected.
Leaving a chatroom on a retraction seems OK, but I would have thought that
leaving when autojoin simply happens to be unset (and might never have been
set) seems wrong.

Your feedback is appreciated!
>

Overall, I think this needs another round of discussion; though I hope this
will be short.

I'll prepare a PR with the changes discussed.

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

[Georg Lukas]

* Jonas Schäfer  [2020-01-29 17:34]:
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?

Yes, it's a significant improvement over existing bookmarks.

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

Yes, mostly (see below).

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

Yes.

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

As stated before, the publish-options need a very prominent mention.

> 5. Is the specification accurate and clearly written?

As was written before, the password should be re-added for backward
compatibility.

Furthermore, I'm missing the following things:


RECOMMENDED name attribute: in past bookmark specifications, this
has led to clients or servers filling the `name` field with the
localpart of the room JID, which made it impossible for the receiving
client to determine whether this is a user-configured name that just
randomly happens to be equal to the localpart, or if it is the "default"
value and the client rather should display the disco#info name of the
room. Please make the name OPTIONAL instead, and add clear advise to
developers that it shall only be populated by the user, not
automatically.


 element: please add implementation notes that a client should
only populate this element if the nickname is different from the
XEP-0172/PEP value, and that when receiving a bookmark without the
nickname, the client SHOULD fall back to the XEP-0172/PEP value.


Persistence: certain PEP implementations from the past, which are still
distributed by major OS platforms, chose to implement PEP in a
non-persistent way, only keeping data in RAM. I know we are deep in
implementation-defined behavior territory here, but a warning to
developers might be appropriate.


Backward compatibility:

First, the wording in the Compatibility section is not very clear:

| A server MAY choose to unify the bookmarks from both Private XML
| Storage (XEP-0049) [2] based and the current Bookmark Storage (XEP-0048)
| [1].

Does that mean that Private XML will be merged into PEP-Bookmarks, but
neither into Bookmarks2? Or is that related to the following statement?
Or the multiple following statements?

Second, I'd like to see better hints to client developers regarding how
to make use of the different server-side capability scenarios.

on a server that doesn't support PEP/publish-options: use 0049

on a server that supports urn:xmpp:bookmarks:0#compat*: use 0402

on a server that just supports 0049 and PEP: ???

I wanted to suggest that a server implementing 0402 must mandatorily
implement both compat mechanisms, but it looks like 0402 doesn't have a
feature var and doesn't depend on explicit server support anyway, so
this point would be moot. However, I'm not sure how to best proceed from
here.


Georg


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

[Daniel Gultsch]

Am Mo., 3. Feb. 2020 um 13:56 Uhr schrieb Maxime Buquet :
>
> 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?

I think there is less overlap with 'Inbox' as this just gives us
faster access to messages from MAM (and won’t even properly handle
MUCs) than there is overlap with a potentially upcoming 'list of open
conversations'.
___
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))

[Daniel Gultsch]

> >Bikeshed: "Atomic Bookmarks in PEP"?
>
> I like it, it's more descriptive.

I agree. It's a much better name.
___
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))

[JC Brand]

Am 30. Januar 2020 11:44:33 MEZ schrieb "Jonas Schäfer" :
>On Donnerstag, 30. Januar 2020 08:45:22 CET Daniel Gultsch wrote:
>> Am Mi., 29. Jan. 2020 um 16:34 Uhr schrieb Jonas Schäfer 
>:
>> > 5. Is the specification accurate and clearly written?
>> 
>> I share Sam’s concerns regarding the title.
>> 
>> 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.
>
>Bikeshed: "Atomic Bookmarks in PEP"?

I like it, it's more descriptive.

- JC



-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
___
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
___

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] 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))

[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))

[Jonas Schäfer]

On Donnerstag, 30. Januar 2020 08:45:22 CET Daniel Gultsch wrote:
> Am Mi., 29. Jan. 2020 um 16:34 Uhr schrieb Jonas Schäfer 
:
> > 5. Is the specification accurate and clearly written?
> 
> I share Sam’s concerns regarding the title.
> 
> 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.

Bikeshed: "Atomic Bookmarks in PEP"?

kind regards,
Jonas

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-0402 (Bookmarks 2 (This Time it's Serious))

[Daniel Gultsch]

Am Mi., 29. Jan. 2020 um 16:34 Uhr schrieb Jonas Schäfer :
>
> 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?

Not really. But it is arguably a better solution to bookmarks than '48.

> 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 an implementation that is currently guarded behind a compile time flag.

I would like to migrate to Bookmarks 2 because adds and deletes are
atomic operations.
In the past I had problems with users deleting 3 bookmarks (from 48
pep) in quick succession. And after deleting the 3 bookmark the
notification for deleting the 1 bookmark would come in and essentially
re-add bookmark #2 back to the list.
This can probably be worked around in the client be maintaining a
deletion queue or something (That reminds me to actually implement
that in Conversations) but it is probably very cumbersome.

Also '48 doesn’t cover immutable server injected bookmarks very well
since it is unspecified what would happen if the user attempts to
delete one; Will the server silently re-add the bookmark? Will it
reject the change?
With 402 the server could just reject the specific delete.

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

In the past we had multiple server- and client-side bugs with PEP that
would accidentally make those bookmarks public to everyone.

The security considerations need to be much more explicit about
publish-options and the bad things that happen if you don’t use it.
(and not just vaguely point to two other XEPs that nobody is going to
read.)

> 5. Is the specification accurate and clearly written?

I share Sam’s concerns regarding the title.

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.

cheers
Daniel
___
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))

[Philipp Hörist]

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

It solves the problem described and introduces a new problem.
Migration to this standard is not possible without data loss.
It removed the  element without any explanation.
Clients who migrate to this standard have no standard way to sync passwords
across devices.
I'm not sure what the thought process was here, the password of the MUC is
known to the server anyway, it does not matter if its stored in a second
place on the same server.

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

I have implemented behind a development flag, but im not sure i want to
really migrate to this standard for reasons described above


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

No


> 5. Is the specification accurate and clearly written?
>

Yes


> 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] LAST CALL: XEP-0402 (Bookmarks 2 (This Time it's Serious))

[Sam Whited]

I would like to mention again that as funny as the title is, we should
stop this trend of putting silly things after the XEP title. They do not
add value, they make it harder to cite (do I really have to write the
joke after every single use of the title when referencing it from
another XEP, for example?), etc.

Please rename this XEP "XEP-0402: Bookmarks 2" or something that's short
and just tells me what it does.

—Sam

On Wed, Jan 29, 2020, at 11: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
> ___
>

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