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

[Kevin Smith]

On 7 Mar 2018, at 19:17, Jonas Wielicki (XSF Editor)  
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
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Kozlov Konstantin]

Hello! 07.03.2018, 22:18, "Jonas Wielicki (XSF Editor)" :The XEP Editor would like to Call for Experience with XEP-0048 beforepresenting 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 theprotocol must be implemented in at least two separate codebases (atleast one of which must be free or open-source software) in order toadvance from Draft to Final.It is implemented in eyeCU and Vacuum-IM. Both of them have the same codebse.2. Have developers experienced any problems with the protocol asdefined in XEP-0048? If so, please describe the problems and, ifpossible, suggested solutions.I'm not the author of implementation, but I just contacted the author and he said that there were no problem with implementation.3. Is the text of XEP-0048 clear and unambiguous? Are more examplesneeded? Is the conformance language (MAY/SHOULD/MUST) appropriate?Have developers found the text confusing at all? Please describe anysuggestions you have for improving the text.No. Everything is all right.If you have any comments about advancing XEP-0048 from Draft to Final,please provide them by the close of business on 2018-03-21. After theCall for Experience, this XEP might undergo revisions to addressfeedback received, after which it will be presented to the XMPPCouncil for voting to a status of Final.With my best regards,Konstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Goffi]

Can't make a detailed review today, so here's quickly:

the XEP is implemented in SàT using both private XML storage (XEP-0049) and 
PEP.

There are several issues with this XEP, the most important being the race 
condition can be specially bad as all bookmarks are saved in the same item.

Also I've tried to use it to bookmark pubsub nodes (blogs) using xmpp: 
URIs, but as it is not explicitly mentioned in the XEP, some clients just 
remove the links (don't remember which ones right now, I've tried years 
ago).

Also on the practical side, the XEP is lacking way to classify links, like 
keywords, hierarchy, or anything else.

We have been thinking for a while with Edhelas about writting an 
alternative proposal for bookmaks actually, but that's an other topic.

Goffi

Le mercredi 7 mars 2018, 20:17:24 CET Jonas Wielicki a écrit :
> 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.
> 
> 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.
> 
> 3. Is the text of XEP-0048 clear and unambiguous? Are more examples
> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate?
> Have developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.
> 
> If you have any comments about advancing XEP-0048 from Draft to Final,
> please provide them by the close of business on 2018-03-21. After the
> Call for Experience, this XEP might undergo revisions to address
> feedback received, after which it will be presented to the XMPP
> Council for voting to a status of Final.
> 
> 
> You can review the specification here:
> 
> https://xmpp.org/extensions/xep-0048.html
> 
> Please send all feedback to the standards@xmpp.org discussion list.
> ___
> 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] Call for Experience: XEP-0048: Bookmarks

[Jonas Wielicki]

On Donnerstag, 8. März 2018 08:28:27 CET Daniel Gultsch wrote:
> 2018-03-08 8:22 GMT+01:00 Jonas Wielicki :
> > On Donnerstag, 8. März 2018 07:38:42 CET Daniel Gultsch wrote:
> >> It feels a bit sad that we aren't able to advance a XEP that is widely
> >> deployed (in a way) but I think it is just too late.
> > 
> > Can’t we revert to XEP-0049 (if no other XEP-0223 implementations show
> > up),
> > advance *that* to final and make a new thing properly based on XEP-0223,
> > with multi-item layout and fancy stuff? I would love if we could take
> > that opportunity to add roster-like groups to bookmarks.
> 
> I don’t think XEP48 over 49 solves the requirements we have today as
> outlined in my previous mail.

That’s very true, even though it *does* reflect the reality. Deprecation 
maybe? Wouldn’t be the first thing we deprecate without real replacement…


> Further advancing that would benefit nobody (I don‘t think we would
> see even more implementations and on the other hand it might confuse
> new comers and guide them towards something that is just not up the
> requirements we have today)

In any case, having the XEP strongly suggest a mechanism which is in fact not 
deployed is also adding (frustrating, because you end up implementing 
something only to learn that it doesn’t work; similar for XEP-0084 vs. 
XEP-0153) confusion for newcomers.

I also think that that the 223 version of things may need more experimentation 
than Draft state may be able to deliver (for example, the single vs. multi-
item issue). Not to mention that multi-item PEP may have even more deployment 
restrictions than persistent, private PEP itself.

But sure, leaving this in Draft as-is would work. But it doesn’t alleviate the 
confusion caused.


> Advancing this only for the sake of advancing something is misguided.

That’s for sure.


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] Call for Experience: XEP-0048: Bookmarks

[Daniel Gultsch]

2018-03-08 8:22 GMT+01:00 Jonas Wielicki :
> On Donnerstag, 8. März 2018 07:38:42 CET Daniel Gultsch wrote:
>> It feels a bit sad that we aren't able to advance a XEP that is widely
>> deployed (in a way) but I think it is just too late.
>
> Can’t we revert to XEP-0049 (if no other XEP-0223 implementations show up),
> advance *that* to final and make a new thing properly based on XEP-0223, with
> multi-item layout and fancy stuff? I would love if we could take that
> opportunity to add roster-like groups to bookmarks.

I don’t think XEP48 over 49 solves the requirements we have today as
outlined in my previous mail.
Further advancing that would benefit nobody (I don‘t think we would
see even more implementations and on the other hand it might confuse
new comers and guide them towards something that is just not up the
requirements we have today)
Advancing this only for the sake of advancing something is misguided.

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

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

[Jonas Wielicki]

On Donnerstag, 8. März 2018 07:38:42 CET Daniel Gultsch wrote:
> It feels a bit sad that we aren't able to advance a XEP that is widely
> deployed (in a way) but I think it is just too late.

Can’t we revert to XEP-0049 (if no other XEP-0223 implementations show up), 
advance *that* to final and make a new thing properly based on XEP-0223, with 
multi-item layout and fancy stuff? I would love if we could take that 
opportunity to add roster-like groups to bookmarks.

This would also solve the documentation issue regarding XEP-0049 usage in this 
XEP which also has been brought up. Not sure if this is cannons against 
sparrows here, just throwing an idea into the room.

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] Call for Experience: XEP-0048: Bookmarks

[Daniel Gultsch]

2018-03-07 20:17 GMT+01:00 Jonas Wielicki :
> 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.

Every implementation and basically just one implementation.

Bookmarks based on 0049 are widely implemented. Bookmarks based on the
recommended PEP are implemented in just one (two~ish) clients.

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

The one and a half implementations based on PEP both messed up:
https://gultsch.de/converse_bookmarks.html

> 3. Is the text of XEP-0048 clear and unambiguous? Are more examples
> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate?
> Have developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.

XEP-0048 seems clear enough to me. But 0223 isn’t clear and you can’t
implement 48 w/o 223. (See the link above)

> If you have any comments about advancing XEP-0048 from Draft to Final,
> please provide them by the close of business on 2018-03-21. After the
> Call for Experience, this XEP might undergo revisions to address
> feedback received, after which it will be presented to the XMPP
> Council for voting to a status of Final.

At this point I wouldn't recommend advancing this XEP.
XEP-0048 based on XEP-0049 has big problems with multi client
environments and long standing sessions. (Usually clients fetch
bookmarks once at connect. Long standing sessions then increase the
time bookmarks go w/o being refreshed)
It is unclear due to the lack of implementation that PEP sufficiently
solves the multi client problems (The problem on whether it is better
to put one bookmark in an item or multiple that was raised already in
this thread.)

It feels a bit sad that we aren't able to advance a XEP that is widely
deployed (in a way) but I think it is just too late. If we had this
discussion five years ago I would have happily advanced a version
based purely on 49. But right know it is stuck in a limbo between the
no longer suitable 49 and the unfinished 223.

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

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

[Kim Alvefur]

On Wed, Mar 07, 2018 at 07:17:24PM -, Jonas Wielicki 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? 

Just about every client, library and server (indirectly, via either
storage mechanism) I've ever seen.

I've myself relied on it in plugins[^1], eg some that provide default
bookmarks to bootstrap new users. Also for having a bot remember which
rooms it should be in[^2].

[^1]: 

[^2]: 

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

Confusion about the storage method, since PEP / XEP-0223 is recommended
but Private XML is commonly used in the wild.

> 3. Is the text of XEP-0048 clear and unambiguous?

The text and tables describing the formats are concise and get the idea
across.

The schema does not appear to match the text, however.

> Are more examples needed?

Always! :)

> Is the conformance language (MAY/SHOULD/MUST) appropriate? Have
> developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.

> > If an element lacks a 'name' attribute, the client SHOULD generate
> > an appropriate subsitution based on other available data.

Reading that, it's not obvious to me whether conformance language is
needed here.

 is NOT RECOMMENDED, but MAY, but SHOULD NOT.

Followed by "MUST enable users [...]" which, like the point about 'name'
above, strikes me as weird.

> If you have any comments about advancing XEP-0048 from Draft to Final,
> please provide them by the close of business on 2018-03-21. After the
> Call for Experience, this XEP might undergo revisions to address
> feedback received, after which it will be presented to the XMPP
> Council for voting to a status of Final.

N/A

> 
> 
> You can review the specification here:
> 
> https://xmpp.org/extensions/xep-0048.html
> 
> Please send all feedback to the standards@xmpp.org discussion list.
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___


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

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

[Christian Schudt]

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

Enough.

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

I didn’t implement the encouraged storage using XEP-0223, sorry. Only old XML 
Storage, no issues there.

> 3. Is the text of XEP-0048 clear and unambiguous? Are more examples
> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate?
> Have developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.

1. It uses the term „Jabber“. Not sure if this is an issue, but I thought it 
should be XMPP.

2. Some inconsistency in the headers, some lower-case, some capital-case:

The conference element
Uploading Data

I think capital-case is the way to go for headers.

3. Although discouraged, an example for usage with Private XML Storage is 
missing (but actually I don’t miss it because its obvious, just pointing it 
out).

4. "In addition, other methods could be used, such as HTTP or WebDAV.“ ==> 
Examples? Unclear what you mean, using a REST service?

5. It’s unclear if multiple bookmarks should be stored as single item each or 
as one big  element which contains all items.

Compare this sentence:
"A bookmark set may contain any number of conference rooms“

to this section:

See https://xmpp.org/extensions/xep-0223.html#composition
"whereas the history of all items published to the node provides a complete 
list of the user's bookmarks"

I think if using Private XML Storage, it’s only possible to use one  
element for all bookmarks.

5. It’s not clear, if one could mix multiple  and  elements 
in the same  element, but I guess yes.

I think the XML schema is wrong:

  

  


  

  

Only allows one of either  or , although the text says:
"A bookmark set may contain any number of conference rooms“
(or the text is wrong)

Should it be this?:

  


  


  


  

or this:

  




  


— Christian

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

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

[Jonas Wielicki]

On Mittwoch, 7. März 2018 20:17:24 CET Jonas Wielicki wrote:
> 1. What software has XEP-0048 implemented?

We have support for Private XML (XEP-0049)-based bookmarks in aioxmpp (LGPLv3) 
and based on that in JabberCat (GPLv3). We haven’t gotten around to implement 
PEP-based bookmarks, even though PEP is generally supported. Lack of proper 
server-side support has delayed that.

> 2. Have developers experienced any problems with the protocol as
> defined in XEP-0048?

- The lack of deployment support for private PEP storage is unfortunate. Until 
recently, documentation was lacking that one should be supporting XEP-0049 
storage at least read-only, too.

- The PEP-based protocol is not ideal. It still stores everything in a single 
item, which makes it prone to race condition issues when multiple clients 
modify the bookmarks at the same time (which could, e.g., happen while an 
invitation is processed). Ideally, PEP storage would use one item per 
bookmark.

> 3. Is the text of XEP-0048 clear and unambiguous? Are more examples
> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate?
> Have developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.

We might want to specify how unknown child elements/attributes on bookmark 
data shall be treated (discard/keep on update). Some implementations have been 
putting extra things there. Maybe the default behaviour follows from RFC 6120 
(which would be discard, I think), but I’m not sure.

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
___

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

[XSF Editor]

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.

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.

3. Is the text of XEP-0048 clear and unambiguous? Are more examples
needed? Is the conformance language (MAY/SHOULD/MUST) appropriate?
Have developers found the text confusing at all? Please describe any
suggestions you have for improving the text.

If you have any comments about advancing XEP-0048 from Draft to Final,
please provide them by the close of business on 2018-03-21. After the
Call for Experience, this XEP might undergo revisions to address
feedback received, after which it will be presented to the XMPP
Council for voting to a status of Final.


You can review the specification here:

https://xmpp.org/extensions/xep-0048.html

Please send all feedback to the standards@xmpp.org discussion list.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___