[Standards] XSF membership application period Q1 2019

[Alexander Gnauck]

I have setup the membership application Wiki page for the application 
period Q1 2019


Applications are encouraged from developers and others who are actively 
involved in the Jabber/XMPP community.

To apply, create a page about yourself on the Wiki:
https://wiki.xmpp.org/web/Membership_Applications_Q1_2019

If you don't have a wiki account, send your full name, preferred 
nickname and email address to me or one of the other Sysops:

http://wiki.xmpp.org/index.php/Sysops

Apply now!!!

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

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

[Jonas Schäfer]

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.

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] LAST CALL: XEP-0345 (Form of Membership Applications)

[Jonas Schäfer]

This message constitutes notice of a Last Call for comments on
XEP-0345.

Note: Since this is a Procedural XEP under control of Board, the Last Call 
mail goes to both standards@ and members@ (only for XSF members) mailing 
lists. This may lead to fragmentation of feedback. The archives of the lists 
are at [1] and [2] respectively.

Title: Form of Membership Applications
Abstract:
This specification outlines the form and mandatory content of
membership applications.

URL: https://xmpp.org/extensions/xep-0345.html

This Last Call begins today and shall end at the close of business on
2018-01-27.

Please consider the following questions during Last Call and send your 
feedback to either or both of the members or the standards discussion list.

1. Is this document needed to fill gaps in the XMPP Standards Foundation's 
policies and procedures, or to clarify an existing XSF policy or procedure?

2. Does the document address the problem stated in the introduction and 
requirements?

3. Should the XSF adopt this document as part of its policies and procedures?

4. Do you have any concerns about the effects of this policy?

5. Is the document accurate and clearly written?

Your feedback is appreciated!

   [1]: https://mail.jabber.org/pipermail/standards/
   [2]: https://mail.jabber.org/pipermail/members/

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] Proposed XMPP Extension: Order-By

[Jonas Schäfer]

For the council record: I’m +1 on this. I think it is useful as-is already. I 
would like to see where this goes. I could imagine generalising the protocol 
to be useful with all types of result sets (e.g. disco#items on MUC).

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] Proposed XMPP Extension: Order-By

[Jonas Schäfer]

On Montag, 7. Januar 2019 19:33:21 CET Goffi wrote:
> Hi Jonas,
> 
> Le lundi 7 janvier 2019, 18:08:25 CET Jonas Schäfer a écrit :
> > On Sonntag, 6. Januar 2019 15:16:43 CET Jonas Schäfer wrote:
> > > Title: Order-By
> > > Abstract:
> > > This specification allows to change order of items retrieval in a
> > > Pubsub or MAM query
> > 
> > Couple notes:
> > 
> > - The strings for the "modification" and "creation" fields (as used in the
> >  element) should be URNs, I think, to allow future extensions
> > without having to worry about conflicts.
> 
> I have thought about that too, but I took XEP-0313 as an example where the
> common filters are using simple keywords ("start", "end", and "with" see
> XEP-0313 § 4.1). So I think this is alright to use keyword for the 2 most
> common cases, and URN for extensions, in the same way as it is done in MAM.

Fair.

> > - Reversal via RSM seems wrong. You also can’t solve reversal via RSM when
> > you use multiple levels of  elements.
> 
> Lets say I have items 1, 2, 3, 4, 5, 6 and I want to get them by creation
> order, 6 being the most recent, with a max of 2 per page, I would get with
> normal request: - 6, 5 (page 1)
> - 4, 3 (page 2)
> - 2, 1 (page 3)
> 
> But if I do backward using RSM's  element, it would be
> 
> - 2, 1 (page 3)
> - 4, 3 (page 2)
> - 6, 5 (page 1)
> 
> (remember, RSM works by pages, so we just get the pages reversed).
> In practice, the order if always DESC. But if the client want's to have ASC,
> it just go backward using RSM, and reverse the result of each page (which
> is trivial), so it would get 1, 2, 3, 4, 5, 6.
> 
> In both cases, requesting `4` gives `6, 5` (i.e. page 1)
> and requesting `3` gives `2, 1` (i.e. page 3).
> 
> Multiple levels of ordering doesn't change anything to the deal, once
> everything is ordered, we end up with a simple list of items.

They do, here’s how: You have two metadata fields, let’s call them Time and 
Author. You have the following data:

Time   Author   Item ID
10:00  Alice1
11:00  Alice2
12:00  Bob  3
13:00  Bob  4
14:00  Bob  5
14:00  Carol6
15:00  Carol7

Suppose I want the posts ordered Ascendingly by Author, and use the time as 
tiebreaker, descendingly. The resulting set would be:

2 1 5 4 3 7 6

There is no way to achieve this ordering with RSM alone.

> > I think this specification needs to be very clear how this stacks with RSM
> > (XEP-0059) and the underlying result set. In my mind, it stacks like this:
> > 
> > PubSub "Database" -> PubSub-level Filters -> order-by XEP -> RSM
> > 
> > I.e. it modifies the base Result Set in RSM terminology.
> 
> Yes RSM is not detailed enough, it's a really important thing to describe,
> I'll work on it on next update. Do you think my example above is clear
> enough?

An example would definitely help.

> > I think this XEP should also provide guidance how to integrate this
> > properly with RSM on the server side: It is not clear to me how a service
> > could sensibly pick  and  item IDs in a way which allows
> > it to reserve the guarantees of delivering a result set which does not
> > lack items which have existed for the entire time the query was being
> > processed (I call this property "completeness"), as well as a
> > duplicate-free result set. If this is not possible (and I believe that to
> > be true), it should be spelt out clearly in the XEP.
> 
> Actually the problematic case is for item overwritting, i.e. if we order by
> "date of modification" according to the protoXEP terms, and this default
> case with XEP-0060 (there is nothing like "modification" or "update", but
> the result is the same: if you overwrite an item, it jump on the top). If
> you use the new order introduced by the protoXEP (date of creation), the
> items won't move, they can only be deleted.

I don’t think that relates to what I was trying to say. RSM relies strongly on 
having a unique, immutable identifier for items (which is used in  
and ). On the *implementation* side (mind, I’m asking specifically for 
implementation guidance), I am not clear on what would be used here. Sure, you 
can use the Item ID, but there’s the problem that you cannot map that to an 
SQL query with ORDER BY. You can use the classic "nth item in result set", but 
that loses the completeness and dub-free guarantees. You can always retrieve 
the full result set from your database and do the RSM paging on the server 
application, but that’s obviously slow.

> > (Note: the guarantees ("completeness" and duplicate-freeness) I am talking
> > about are a "MAY" in RSM, §2.2, bullet points 2 and 3.)
> 
> yes I was about to mention it is a "MAY" too :). But I totally agree with
> your points, I'll explain it clearly in next revision.

> > I am not completely sure whether it wouldn’t make more sense to specify an
> > extension which allows to sort by arbitrary (or specific) Atom fields and
> > let the Atom feed handle the management of modification/creation values.
> > This also