[Standards] Call for Experience: XEP-0048: Bookmarks

Kevin Smith kevin.smith at isode.com
Wed Mar 21 11:32:40 UTC 2018


On 7 Mar 2018, at 19:17, Jonas Wielicki (XSF Editor) <jonas at wielicki.name> wrote:
> The XEP Editor would like to Call for Experience with XEP-0048 before
> presenting it to the Council for advancing it to Final status.
> 
> 
> During the Call for Experience, please answer the following questions:
> 
> 1. What software has XEP-0048 implemented? Please note that the
> protocol must be implemented in at least two separate codebases (at
> least one of which must be free or open-source software) in order to
> advance from Draft to Final.

We’ve got this implemented in Swiften/Stroke/Swift, but it’s the old iq:private-based version, not the currently defined PIP version. We also don’t do anything with URLs, only Conferences.

> 2. Have developers experienced any problems with the protocol as
> defined in XEP-0048? If so, please describe the problems and, if
> possible, suggested solutions.

It’s not clear that you can easily lose data when publishing if other clients have extended entities in unexpected ways and that you have to jump through hoops to avoid this.
While not strictly a problem with the protocol, the presence of the URL stuff doesn’t seem to be helpful, and thus adds complexity where it doesn’t seem to be needed.
Putting all bookmarks in a single element doesn’t seem like a sensible use of pubsub.
There are potential privacy concerns around defaults when no nick is specified, and it makes sense to discuss this in the XEP.
Expected behaviour when receiving autojoin pushes on a live session should be discussed, as should receipt of a push that removes an autojoin for a room that you joined because of the autojoin.
I think pushing to Final without sufficient reference to the current deployments primarily being iq:private-based wouldn’t be sensible.
I think some words about publish options are needed, given confusion here.

/K


More information about the Standards mailing list