Re: [Standards] SASL2 Update incoming

[Dave Cridland]

On 25 August 2017 at 18:53, Evgeny Khramtsov  wrote:
> In fact, I would like to see
> log-in procedure in a *single* request-response and in this case we
> gain a lot, I can even resign myself to significant RFC replacement in
> this case.

https://xmpp.org/extensions/xep-0388.html#sect-idm45097655269792

That does the authentication itself in 1-RTT, assuming that a client
pipelines the authenticate with the stream-open and has cached the
features.

We can add more features to this (resource binding, roster versioning,
MAM/Carbons/etc) quite easily, which we cannot with the RFC SASL.

SASL2 is *not* a panacea, as Sam says - but it is an enabling measure.

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

Re: [Standards] SASL2 Update incoming

[Ivan Vučica]

On August 25, 2017 6:53:43 PM GMT+01:00, Evgeny Khramtsov  
wrote:
>Fri, 25 Aug 2017 12:29:55 -0500
>Sam Whited  wrote:
>> We can't just skip auth and go straight to the roster
>
>Sure we can

Presence  value is also useful information. I am more likely to email an 
offline contact than send them an offline message.

Sooner I see my contacts' availability, happier I am.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] SASL2 Update incoming

[Evgeny Khramtsov]

Fri, 25 Aug 2017 12:29:55 -0500
Sam Whited  wrote:

> Then it's an even worse UX when auth fails and users think their
> messages have been sent (or they fail to send anyways)

Which happens like 1 times out of thousands. I think it's better to
act optimistically. I also tend to think that server/traffic lagging is
much more frequent event and such pessimistic behaviour only worsen
this.

> We can't just skip auth and go straight to the roster

Sure we can

> Also, this doesn't account for the first time when they don't have
> the roster synced yet.

This happens a single time on the first launch. I don't remember
software acting reactively on the first start.

> No one said that this was a panacea and was the *only* thing to be
> done to make everyones lives magically better.

And we return to my point: we have really little gain from such
invasive XEP: it re-writes quite large part of the RFC.

> Also, lots of users *do* have a really poor connection.

That's true, a lot. But much more people have fast connection and the
traffic statistics proves that: 80% of traffic is now media
(youtube+instagram+etc). I think we need to cover this use case in the
first place if we want XMPP to survive. But it's ok for me adding the
XEP for some rare use cases, of course. In fact, I would like to see
log-in procedure in a *single* request-response and in this case we
gain a lot, I can even resign myself to significant RFC replacement in
this case.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] SASL2 Update incoming

[Sam Whited]

On Fri, Aug 25, 2017, at 12:22, Evgeny Khramtsov wrote:
> But why do you wait for the stream to be established? You can write
> messages to a buffer, you already have one anyhow if you support
> XEP-0198. This is a problem of a bad UX, not the protocol.

Then it's an even worse UX when auth fails and users think their
messages have been sent (or they fail to send anyways). We can't just
skip auth and go straight to the roster. Also, this doesn't account for
the first time when they don't have the roster synced yet.

> I also don't believe that you will gain more than 100ms unless you have
> really poor connection.

No one said that this was a panacea and was the *only* thing to be done
to make everyones lives magically better. Also, lots of users *do* have
a really poor connection.

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

Re: [Standards] SASL2 Update incoming

[Evgeny Khramtsov]

Fri, 25 Aug 2017 12:13:56 -0500
Sam Whited  wrote:

> The longer your connection takes after 100ms, the more likely it is
> that users will close your application. It is *more* important to make
> connection times faster than it is to make any other part of the
> stream fast, because this is the most noticeable place where things
> might be slow.

But why do you wait for the stream to be established? You can write
messages to a buffer, you already have one anyhow if you support
XEP-0198. This is a problem of a bad UX, not the protocol.

I also don't believe that you will gain more than 100ms unless you have
really poor connection.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] SASL2 Update incoming

[Sam Whited]

On Fri, Aug 25, 2017, at 11:59, Evgeny Khramtsov wrote:
> Maybe a significant reduction in RTT, but this is a little part of the
> whole session traffic (the large part of which are pointless presences
> and some PEP). So you will connect in 1 second instead of 2. No? Then
> do you have benchmarking?

This is not about reducing bandwidth costs or overall traffic, it's
about reducing startup latency. A "connection" (defined by the time a
user clicks on an icon on their desktop or wherever to the time they can
send a message) that takes longer than 100ms is noticeable to the user.
The longer your connection takes after 100ms, the more likely it is that
users will close your application. It is *more* important to make
connection times faster than it is to make any other part of the stream
fast, because this is the most noticeable place where things might be
slow.

Unfortunately, I no longer work somewhere that makes a large commercial
chat product, so I don't have access to our data, but we had quite a lot
of it that showed that the first few seconds of using an app are the
time when a user makes a judgement about the application.  There was a
direct correlation between increased startup times and users hitting the
close button. Similarly, as we reduced startup times our NPS went up by
several points compared to users that did not have the version with
reduced startup times. It's important.

FWIW, an implementation I attempted also uses a state machine, and I
found it trivial to add support for this profile after already having an
implementation of the RFC 6120 SASL profile.

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

Re: [Standards] SASL2 Update incoming

[Evgeny Khramtsov]

Fri, 25 Aug 2017 17:39:14 +0100
Dave Cridland  wrote:

> 1) On the server side, handling both SASL profiles is actually
> surprisingly simple, in my experience. The protocol as documented is
> based on actually implementing it in full.  

I disagree. Maybe a mess with if/else is okay for you, but not for me.
I have a well-defined finite state machine, adding new SASL means that I
need to expand it, adding more states and transitions and this
definitely complicates the FSM.

> 2) Two-factor authentication isn't like two lots of single-factor. I
> was surprised too - you'll note that this was how the first version
> was modelled, and it's a real pain to make work.  

Not sure why it's significantly harder to implement, but ok.

> 3) I felt it was simpler to ensure that on , the stream was
> authenticated, whereas before it wasn't. Simplifies stream security.  

I didn't get this. How on earth  could mean the stream is not
authenticated?

> 4) I'm not motivated to write this because client developers are
> pussies - I don't think they are. I'm motivated to write this because
> our general framework for session establishment in XMPP is an
> organically grown mess, and starting over seems reasonable if the
> gains are high enough.  

That's true. But our way looks like patching the mess, instead of
getting rid of it.

> We gain solid 2FA  

OK

> significant RTT reduction  

Maybe a significant reduction in RTT, but this is a little part of the
whole session traffic (the large part of which are pointless presences
and some PEP). So you will connect in 1 second instead of 2. No? Then
do you have benchmarking?

> and atomic session establishment  

Yeah, I would like to see its fantastic atomicity in practice.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] SASL2 Update incoming

[Dave Cridland]

On 25 August 2017 at 17:18, Evgeny Khramtsov  wrote:
> Fri, 25 Aug 2017 12:33:54 +0100
> Dave Cridland  wrote:
>
>> Comments are most welcome!
>
> While the spec itself is okayish at the first glance, I think it creates
> more problems than it solves. Really, two-factor authentication can be
> done using sequential SASL auth with stream restarts, requirement for
> password change can be done by updating XEP-0077 (using mandatory to
> negotiate feature, as I suggested in the previous discussion of the
> topic), a bind+resume+mam combo can be wrapped into some transation,
> hell, even stream restarts can be avoided by telling "hey, don't
> restart the stream, it's stupid" (because why not, we already bypass
> RFC6120 rules in this proto XEP). I personally really don't know how
> this solves problems of client developers, but for me, as a server
> developers, all this creates additional burden, because I need to
> maintain both SASL protocols anyhow, blowing already over-complicated
> stream management, so this only creates complexity for me. I'm
> absolutely not motivated implementing this just because client
> developers are pussies who failed to write code, and I really don't
> understand why otherwise one needs this new SASL stuff - I don't
> consider stream restarts and sequential stanza processing as a problem.
> Another problem is that with specs like this we move far and far away
> from RFC6120, rendering it more and more useless.

So:

1) On the server side, handling both SASL profiles is actually
surprisingly simple, in my experience. The protocol as documented is
based on actually implementing it in full.

2) Two-factor authentication isn't like two lots of single-factor. I
was surprised too - you'll note that this was how the first version
was modelled, and it's a real pain to make work.

3) I felt it was simpler to ensure that on , the stream was
authenticated, whereas before it wasn't. Simplifies stream security.

4) I'm not motivated to write this because client developers are
pussies - I don't think they are. I'm motivated to write this because
our general framework for session establishment in XMPP is an
organically grown mess, and starting over seems reasonable if the
gains are high enough.

5) The gains really are high. We gain solid 2FA, significant RTT
reduction, and atomic session establishment. Well, I hope.

But yeah, please do hold me to that goal.

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

Re: [Standards] SASL2 Update incoming

[Evgeny Khramtsov]

Fri, 25 Aug 2017 12:33:54 +0100
Dave Cridland  wrote:

> Comments are most welcome!

While the spec itself is okayish at the first glance, I think it creates
more problems than it solves. Really, two-factor authentication can be
done using sequential SASL auth with stream restarts, requirement for
password change can be done by updating XEP-0077 (using mandatory to
negotiate feature, as I suggested in the previous discussion of the
topic), a bind+resume+mam combo can be wrapped into some transation,
hell, even stream restarts can be avoided by telling "hey, don't
restart the stream, it's stupid" (because why not, we already bypass
RFC6120 rules in this proto XEP). I personally really don't know how
this solves problems of client developers, but for me, as a server
developers, all this creates additional burden, because I need to
maintain both SASL protocols anyhow, blowing already over-complicated
stream management, so this only creates complexity for me. I'm
absolutely not motivated implementing this just because client
developers are pussies who failed to write code, and I really don't
understand why otherwise one needs this new SASL stuff - I don't
consider stream restarts and sequential stanza processing as a problem.
Another problem is that with specs like this we move far and far away
from RFC6120, rendering it more and more useless.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Atomically Compare-And-Publish PubSub Items

[Florian Schmaus]

On 25.08.2017 16:25, Jonas Wielicki wrote:
> On Freitag, 25. August 2017 16:22:56 CEST Florian Schmaus wrote:
>> Well that complicates a potential compare-and-publish (CAP) protocol
>> somewhat. Then indeed we need to define a new unique handle which refers
>> to the latest node item state and changes if the item changes in any way
>> (regardless whether the item id stays equal or not).
>>
>> It would be much easier if xep60 would guarantee the node's content
>> could not change without a node ID change. I condemn that design
>> decision a bit.
> 
> Surely you mean Item Id and Item in the last paragraph?

Item ID, yes.

- 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] SASL2 Update incoming

[Sam Whited]

On Fri, Aug 25, 2017, at 09:22, Dave Cridland wrote:
> So the problem with that is that the schemas for the feature and the
> (same-named) top-level element wouldn't match.

That seems fine to me, but I also don't understand XML schema so I might
just not understand why that's a problem. How do other features handle
this since they mostly use the same names?

> On a similar note, however, you cannot design every stream feature
> such that the negotiation method is to send the feature element as a
> top-level element.

Actual serious question: Why not?

> I think it's reasonable to try to ensure that every stream feature's
> namespace is the same as any top-level elements it uses; but that rule
> has already been broken with dialback.

I had forgotten about dialback; I'm not suggesting we change all old
features though (nice as that would be), just that new ones try to stick
to this rule.

> I can spin up a server with this running if you like.

That would actually be really nice; I've only tested against a server
using the same implementation, so chances are mistakes wouldn't be
noticeable.

On Fri, Aug 25, 2017, at 09:27, Jonas Wielicki wrote:
> it also may complicate implementations which map XML elements to 
> objects; they would then need context about where the element occurs to
> pick  the object to map it to.

That's actually my use case, this is context you always have though. If
I'm a server and I read from the connection expecting a stream feature
to be selected, I know if I need to unmarshal into a request or response
struct.

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

Re: [Standards] SASL2 Update incoming

[Jonas Wielicki]

On Freitag, 25. August 2017 15:22:20 CEST Dave Cridland wrote:
> On 25 August 2017 at 15:03, Sam Whited  wrote:
> > On Fri, Aug 25, 2017, at 06:33, Dave Cridland wrote:
> >> Comments are most welcome!
> > 
> > The only thing I think needs to be changed right now, though it sounds
> > minor, is that the response to select the SASL stream feature does not
> > match the feature advertised. The server offers "" and the
> > client responds with ". While I know there's no
> > requirement in 6120 that these match, it's an assumption that would be
> > nice to be able to make in some future stream negotiation protocol (and,
> > in my experience, simplifies writing stream feature APIs). Doing it now
> > could help ensure future compatibility. The current SASL profile is, I
> > think, the only widely used stream feature where the response does not
> > match the advertised feature, so it would also be nice for consistencies
> > sake if nothing else.
> 
> So the problem with that is that the schemas for the feature and the
> (same-named) top-level element wouldn't match.
> 
> On the one hand, I don't care, but on the other, it makes it hard to
> document.

Yes, that is not possible with XML Schemas. Aside from the documentation 
difficulties, it also may complicate implementations which map XML elements to 
objects; they would then need context about where the element occurs to pick 
the object to map it to.

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: Atomically Compare-And-Publish PubSub Items

[Jonas Wielicki]

On Freitag, 25. August 2017 16:22:56 CEST Florian Schmaus wrote:
> Well that complicates a potential compare-and-publish (CAP) protocol
> somewhat. Then indeed we need to define a new unique handle which refers
> to the latest node item state and changes if the item changes in any way
> (regardless whether the item id stays equal or not).
> 
> It would be much easier if xep60 would guarantee the node's content
> could not change without a node ID change. I condemn that design
> decision a bit.

Surely you mean Item Id and Item in the last paragraph?

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: Atomically Compare-And-Publish PubSub Items

[Florian Schmaus]

On 25.08.2017 13:39, Dave Cridland wrote:
> On 25 August 2017 at 10:17, Florian Schmaus  wrote:
>> On 25.08.2017 10:08, Dave Cridland wrote:
>>> This is most particularly acute in PEP cases, where the single
>>> item id is traditionally fixed.
>>
>> Isn't the item ID always fixed, stable and unique (see xep60 § 12.8)?
>> I've a sense that there is some confusion about item and node wrt. to
>> PubSub. Maybe on my side.
>>
> 
> The last id is fixed for a given publish, is stable throughout the
> item's lifetime, and is unique at a given instant for a node.
> 
> It is not, however, unique for all time, since they can be reused.
> 
>>> As a strawman counter-proposal, what about:
>>>
>>> * Defining a mechanism similar to roster versioning for pubsub nodes.
>>> * From there, defining a conditional publish based on the node version.
>>
>> What's the difference between the PubSub node version you propose and
>> defining the PubSub node "version" as the item ID of the newest item of
>> a PubSub node (which my XEP does)?
> 
> I think my strawman will handle a retraction, which - again I think -
> your proposal would not.
Ugh, my assumption was that the same node ID will always refer to the
same content of an . But after re-reading xep60 § 12.8 I found
the following:

"""
If a publisher publishes an item and the ItemID matches that of an
existing item, the pubsub service MUST overwrite the existing item and
generate a new event notification.
"""

Well that complicates a potential compare-and-publish (CAP) protocol
somewhat. Then indeed we need to define a new unique handle which refers
to the latest node item state and changes if the item changes in any way
(regardless whether the item id stays equal or not).

It would be much easier if xep60 would guarantee the node's content
could not change without a node ID change. I condemn that design
decision a bit.

But anyway, it appears we have to live with it. I'll work on an updated
version of CAP in the following days/weeks.

- 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] SASL2 Update incoming

[Dave Cridland]

On 25 August 2017 at 15:03, Sam Whited  wrote:
> On Fri, Aug 25, 2017, at 06:33, Dave Cridland wrote:
>> Comments are most welcome!
>
> The only thing I think needs to be changed right now, though it sounds
> minor, is that the response to select the SASL stream feature does not
> match the feature advertised. The server offers "" and the
> client responds with ". While I know there's no
> requirement in 6120 that these match, it's an assumption that would be
> nice to be able to make in some future stream negotiation protocol (and,
> in my experience, simplifies writing stream feature APIs). Doing it now
> could help ensure future compatibility. The current SASL profile is, I
> think, the only widely used stream feature where the response does not
> match the advertised feature, so it would also be nice for consistencies
> sake if nothing else.
>

So the problem with that is that the schemas for the feature and the
(same-named) top-level element wouldn't match.

On the one hand, I don't care, but on the other, it makes it hard to document.

On a similar note, however, you cannot design every stream feature
such that the negotiation method is to send the feature element as a
top-level element.

I think it's reasonable to try to ensure that every stream feature's
namespace is the same as any top-level elements it uses; but that rule
has already been broken with dialback.

So anyway, if we're to have exceptions to the general rule, it's nice
if one of them is (hopefully) the first one clients will be using.

> Thanks for all your work on this! I'll hopefully update my
> implementation with your changes soon.

I can spin up a server with this running if you like.

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

Re: [Standards] SASL2 Update incoming

[Sam Whited]

On Fri, Aug 25, 2017, at 06:33, Dave Cridland wrote:
> Comments are most welcome!

The only thing I think needs to be changed right now, though it sounds
minor, is that the response to select the SASL stream feature does not
match the feature advertised. The server offers "" and the
client responds with ". While I know there's no
requirement in 6120 that these match, it's an assumption that would be
nice to be able to make in some future stream negotiation protocol (and,
in my experience, simplifies writing stream feature APIs). Doing it now
could help ensure future compatibility. The current SASL profile is, I
think, the only widely used stream feature where the response does not
match the advertised feature, so it would also be nice for consistencies
sake if nothing else.

Thanks for all your work on this! I'll hopefully update my
implementation with your changes soon.

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

[Standards] UPDATED: XEP-0388 (Extensible SASL Profile)

[XSF Editor]

Version 0.2.1 of XEP-0388 (Extensible SASL Profile) has been released.

Abstract:
This document describes a replacement for the SASL profile documented
in RFC 6120 which allows for greater extensibility.

Changelog:
(see in-document revision history)

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

Re: [Standards] Proposed XMPP Extension: Atomically Compare-And-Publish PubSub Items

[Dave Cridland]

On 25 August 2017 at 10:17, Florian Schmaus  wrote:
> On 25.08.2017 10:08, Dave Cridland wrote:
>> I think the premise looks reasonable - that is, a publish conditional
>> on the last item to be published being known.
>>
>> However, this protocol as defined has several flaws:
>>
>> * It doesn't do what it claims.
>> * It's an awkward syntax.
>> * It fails to define what "latest id" means.
>
> Thanks for your feedback Dave.
>
>> Going through each:
>>
>> * It doesn't do what it claims
>>
>> Given the following sequence, the "Compare And Publish" will
>> unexpectedly work when it should fail:
>>
>> 1) Publish to Item 1
>> 2) Event for Item 1
>> 3) Publish to Item 1
>> 4) Publish Item 2 conditional on Item 1 being "latest"
>> 5) Event for Item 1
>> 6) Event for Item 2
>>
>> In other words, the race this protocol attempts to resolve still
>> exists.
>
> I'm confused that you talk about publishing to a *item*. My assumption
> was that you publish to nodes, where every node has a ordered list of items.
>

Yes, I wasn't clear. Publish to a node with a client-supplied item id.

> Is 3) a publish without compare-and-publish? If so, then yes the race
> still would exists. As soon as one participant does not use
> compare-and-publish, the race can't be solved (without enforcing
> compare-and-publish server-side).
>

Actually, even if the publish in (3) is conditional, I think the same
thing applies - because item ids can be (and often are) reused, merely
knowing the last id published does not indicate that the client knows
what the item payload was.

>> This is most particularly acute in PEP cases, where the single
>> item id is traditionally fixed.
>
> Isn't the item ID always fixed, stable and unique (see xep60 § 12.8)?
> I've a sense that there is some confusion about item and node wrt. to
> PubSub. Maybe on my side.
>

The last id is fixed for a given publish, is stable throughout the
item's lifetime, and is unique at a given instant for a node.

It is not, however, unique for all time, since they can be reused.

>> As a strawman counter-proposal, what about:
>>
>> * Defining a mechanism similar to roster versioning for pubsub nodes.
>> * From there, defining a conditional publish based on the node version.
>
> What's the difference between the PubSub node version you propose and
> defining the PubSub node "version" as the item ID of the newest item of
> a PubSub node (which my XEP does)?

I think my strawman will handle a retraction, which - again I think -
your proposal would not.

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

[Standards] SASL2 Update incoming

[Dave Cridland]

Folks,

After discovering how confusing and badly-written some parts of the
spec are, thanks to Phil Roberts, I've updated once more, fixing a few
XML errors and also adding some example flows to illustrate the
protocol a little.

Also, I added an XML Schema, which should help clarify, for those who
read those.

Comments are most welcome!

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

Re: [Standards] Proposed XMPP Extension: Atomically Compare-And-Publish PubSub Items

[Florian Schmaus]

On 24.08.2017 22:40, Kim Alvefur wrote:
> Since publish-options is defined such that you can register fields in it
> as preconditions, having a precondition on the previous last ID seems
> fairly natural.

How is this: http://geekplace.eu/xeps/xep-cap/xep-cap.html ?

- 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] Proposed XMPP Extension: Atomically Compare-And-Publish PubSub Items

[Florian Schmaus]

On 24.08.2017 22:40, Kim Alvefur wrote:
> Hi,
> 
> On Thu, Aug 24, 2017 at 12:10:33PM -, Jonas Wielicki wrote:
>> Title: Atomically Compare-And-Publish PubSub Items
>> Abstract:
>> This specification provides a mechanism to atomically Compare-And-
>> Publish items to a PubSub node.
> 
> Why not define this as a publish-options field?
> 
> Eg something like this:
> 
> ``` xml
>  id="pub1">
>   http://jabber.org/protocol/pubsub;>
>   
>   
>   http://www.w3.org/2005/Atom;>
>   Soliloquy
>   
> To be, or not to be: that is the question:
> Whether 'tis nobler in the mind to suffer
> The slings and arrows of outrageous fortune,
> Or to take arms against a sea of troubles,
> And by opposing end them?
>   
>href="http://denmark.lit/2003/12/13/atom03"/>
>   
> tag:denmark.lit,2003:entry-32397
>   
> 2003-12-13T18:30:02Z
>   2003-12-13T18:30:02Z
>   
>   
>   
>   
>   
>   
>   
> http://jabber.org/protocol/pubsub#publish-options
>   
>   
>   1
>   
>   
>   
>   
> 
> ```
> 
> Since publish-options is defined such that you can register fields in it
> as preconditions, having a precondition on the previous last ID seems
> fairly natural.

Very good point. I remembered again that this was the initial design
choice when I thought about this years ago. Will change.

- 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] Proposed XMPP Extension: Atomically Compare-And-Publish PubSub Items

[Florian Schmaus]

On 25.08.2017 10:08, Dave Cridland wrote:
> I think the premise looks reasonable - that is, a publish conditional
> on the last item to be published being known.
> 
> However, this protocol as defined has several flaws:
> 
> * It doesn't do what it claims.
> * It's an awkward syntax.
> * It fails to define what "latest id" means.

Thanks for your feedback Dave.

> Going through each:
> 
> * It doesn't do what it claims
> 
> Given the following sequence, the "Compare And Publish" will
> unexpectedly work when it should fail:
> 
> 1) Publish to Item 1
> 2) Event for Item 1
> 3) Publish to Item 1
> 4) Publish Item 2 conditional on Item 1 being "latest"
> 5) Event for Item 1
> 6) Event for Item 2
> 
> In other words, the race this protocol attempts to resolve still
> exists.

I'm confused that you talk about publishing to a *item*. My assumption
was that you publish to nodes, where every node has a ordered list of items.

Is 3) a publish without compare-and-publish? If so, then yes the race
still would exists. As soon as one participant does not use
compare-and-publish, the race can't be solved (without enforcing
compare-and-publish server-side).

> This is most particularly acute in PEP cases, where the single
> item id is traditionally fixed.

Isn't the item ID always fixed, stable and unique (see xep60 § 12.8)?
I've a sense that there is some confusion about item and node wrt. to
PubSub. Maybe on my side.

All in all, the point you are trying to make here is not clear to me.

> * It's an awkward syntax
> 
> A matter of taste, to be certain, but nevertheless there are some
> frankly weird choices here:
> 
> - It's a publish, but it's not a , 

I think that's similar to what Kim suggested: Using a publish-options
field instead of a new element ().  I'll will
comment on that as reply to Kim's mail later.

> nor even an extension to  XEP-0060's 

Would it be a good idea to define a new child element for  in an add-on XEP? I don't
think so, that's why it's not an xep60 .

> - Failure cases are given as an  of type "result".

Hmm, it's been a while ago when I wrote that. I'm pretty sure I had some
reasons but can't remember. Happy to change that to 'error'.


> * It fails to define what "latest id" means.
> 
> Is this the latest id to have had an item published? I'm reasonably
> sure it is, based on the surrounding prose, but it could also be the
> latest id to be newly minted, in which case I have the entire premise
> incorrect.

Good point, I think. When is an item minted but not published? Are
PubSub services allowed to make a new item visible prior sending the
event for the new item? I guess there is always a inconsistent state
between the event notification arriving at an entity, and that entity
querying the node's item(s).

> As a strawman counter-proposal, what about:
> 
> * Defining a mechanism similar to roster versioning for pubsub nodes.
> * From there, defining a conditional publish based on the node version.

What's the difference between the PubSub node version you propose and
defining the PubSub node "version" as the item ID of the newest item of
a PubSub node (which my XEP does)?

- Florian



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