Re: [Standards] XEP-0227 update
On Wed, Jul 14, 2021 at 02:13:19PM +0100, Matthew Wild wrote: On Wed, 14 Jul 2021 at 12:12, Matthew Wild wrote: I think your point and Kev's are somewhat related. The current proposal does not allow for preservation of explicit subscriptions or affiliations. I think today's reality is that everyone is doing full pubsub on the account JID, and it makes sense to preserve this information as well. If there are no objections, I'll add some text about this, and allow for inclusion of a single and element, as documented in: - https://xmpp.org/extensions/xep-0060.html#example-25 (subscriptions) - https://xmpp.org/extensions/xep-0060.html#example-27 (affiliations) It's awkward that it's a single element rather than one per node (as with items and configure), but there we are. Never mind. Elsewhere in XEP-0060 I found more appropriate elements that list subscriptions/affiliations for an individual node. I've updated the PR, and pushed a rendered copy here: https://matthewwild.co.uk/uploads/xep-0227.html#pep There is a minor addition to 4.10 about non-PEP features, but most of the new text is in 4.10.1, and I updated the example to show the new elements. LGTM -- Kim "Zash" Alvefur XSF Council signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0227 update
On Wed, 14 Jul 2021 at 12:12, Matthew Wild wrote: > I think your point and Kev's are somewhat related. The current > proposal does not allow for preservation of explicit subscriptions or > affiliations. I think today's reality is that everyone is doing full > pubsub on the account JID, and it makes sense to preserve this > information as well. > > If there are no objections, I'll add some text about this, and allow > for inclusion of a single and element, > as documented in: > > - https://xmpp.org/extensions/xep-0060.html#example-25 (subscriptions) > - https://xmpp.org/extensions/xep-0060.html#example-27 (affiliations) > > It's awkward that it's a single element rather than one per node (as > with items and configure), but there we are. Never mind. Elsewhere in XEP-0060 I found more appropriate elements that list subscriptions/affiliations for an individual node. I've updated the PR, and pushed a rendered copy here: https://matthewwild.co.uk/uploads/xep-0227.html#pep There is a minor addition to 4.10 about non-PEP features, but most of the new text is in 4.10.1, and I updated the example to show the new elements. Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0227 update
On Tue, 29 Jun 2021 at 13:40, Kim Alvefur wrote: > > Hi, > > On Wed, Jun 02, 2021 at 04:59:40PM +0100, Matthew Wild wrote: > >I've prepared an update that adds some of the missing features: > > - PEP nodes (configuration and items) > > What about explicit subscriptions and affiliations relevant? While not > strictly required for basic PEP, there are implementations that support > more optional (for PEP) PubSub features including support for > subscriptions and affiliations that aren't attached to presence > subscriptions. And with that covered by XEP-0227 then it might not be > far from being usable for PubSub (components etc) exports as well. I think your point and Kev's are somewhat related. The current proposal does not allow for preservation of explicit subscriptions or affiliations. I think today's reality is that everyone is doing full pubsub on the account JID, and it makes sense to preserve this information as well. If there are no objections, I'll add some text about this, and allow for inclusion of a single and element, as documented in: - https://xmpp.org/extensions/xep-0060.html#example-25 (subscriptions) - https://xmpp.org/extensions/xep-0060.html#example-27 (affiliations) It's awkward that it's a single element rather than one per node (as with items and configure), but there we are. Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0227 update
Hi, On Wed, Jun 02, 2021 at 04:59:40PM +0100, Matthew Wild wrote: I've prepared an update that adds some of the missing features: - PEP nodes (configuration and items) What about explicit subscriptions and affiliations relevant? While not strictly required for basic PEP, there are implementations that support more optional (for PEP) PubSub features including support for subscriptions and affiliations that aren't attached to presence subscriptions. And with that covered by XEP-0227 then it might not be far from being usable for PubSub (components etc) exports as well. -- Kim "Zash" Alvefur ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0227 update
Thanks Matt, a couple of comments: On not namespace bumping: 227 already said you had to cope with unexpected elements, so simply including the new elements in their new namespaces seems ok to me. (Although this may generate warnings. *shrug*) PEP: Do you mean PEP as in 163, or full pubsub-on-a-JID? I assume the latter - is it worth being explicit? What needs to happen if you can’t process the config fully on import (because of features the exporting server supports and you don’t). But otherwise looks good, thanks. /K > On 2 Jun 2021, at 16:59, Matthew Wild wrote: > > Hi folks, > > This somewhat forgotten XEP used to be the way to migrate data between > XMPP services. Unfortunately it didn't keep up with the times, and > many servers gained tools for importing directly from the native > formats of other servers (Prosody has an ejabberd importer, ejabberd > has a Prosody importer). > > Even if it never again becomes the standard format for server software > migrations (XML is not an ideal format when you're dealing with > massive amounts of data), as part of the XMPP account portability > project[1] I want to once again bring XEP-0227 up to date with what > data commonly constitutes an XMPP account. > > I've prepared an update that adds some of the missing features: > > - SCRAM hashes (it previously recommended inclusion of plaintext passwords) > - PEP nodes (configuration and items) > - Message archives > > I'd appreciate feedback, and also I'd be curious of any wishlist items > that anyone else may have. > > The draft PR is at: https://github.com/xsf/xeps/pull/1064 and a > rendered version is available at > https://matthewwild.co.uk/uploads/xeps/xep-0227.html > > Regards, > Matthew > > [1]: https://docs.modernxmpp.org/projects/portability/ > ___ > 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] XEP-0227 update
Hi list,
On Mittwoch, 23. Juni 2021 20:05:20 CEST Matthew Wild wrote:
> On Wed, 23 Jun 2021, 17:21 Guus der Kinderen,
>
> wrote:
> > Should we consider introducing a change to the namespace as used in the
> > portable data, to more explicitly handle the changes in format? I'm aware
> > that you mainly introduced new elements, and the one attribute that you
> > dropped ('password') is defined as a 'should' - but still: the output is
> > significantly different.
>
> I'm not sure I agree that it's *significantly* different. As you say, it's
> mostly adding new stuff. So let's see...
>
> If we use existing namespace for old elements:
>
> [… snip …]
>
> My thoughts: the goal of XEP-0227 is about maximizing interoperability
> between servers. Bumping the namespace on elements that have not changed
> their format reduces interoperability.
I agree; as long as the new elements are in a new namespace (and they are), I
think we’re good.
> > Given the nature of the protocol, it is not unthinkable that data exported
> > by an implementation following the older XEP version gets imported by one
> > of a newer version, and vice versa - perhaps with plenty of time between
> > import and export (eg: backup restores).
Important argument which supports Matthews approach IMO.
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] XEP-0227 update
Hi,
Thanks for your feedback!
On Wed, 23 Jun 2021, 17:21 Guus der Kinderen,
wrote:
> Should we consider introducing a change to the namespace as used in the
> portable data, to more explicitly handle the changes in format? I'm aware
> that you mainly introduced new elements, and the one attribute that you
> dropped ('password') is defined as a 'should' - but still: the output is
> significantly different.
>
I'm not sure I agree that it's *significantly* different. As you say, it's
mostly adding new stuff. So let's see...
If we use existing namespace for old elements:
- a file exported by a new implementation but imported by an old
implementation will import roster, bookmarks and everything else defined in
the previous version of the spec. It won't import passwords (but this is
probably true of most servers using the old format too, since plaintext
passwords are not available in most deployments). It also won't import PEP
and MAM, but those have never been supported previously anyway.
- a file exported by an old implementation but imported by the new will
work just as the old format did.
If we switch to a new namespace for everything:
- a file exported by a new implementation but imported by an old
implementation will fail to be recognised, making it impossible to import
anything.
- a file exported by an old implementation but imported by the new will
work if new implementations add code to support both versions.
My thoughts: the goal of XEP-0227 is about maximizing interoperability
between servers. Bumping the namespace on elements that have not changed
their format reduces interoperability.
Given the nature of the protocol, it is not unthinkable that data exported
> by an implementation following the older XEP version gets imported by one
> of a newer version, and vice versa - perhaps with plenty of time between
> import and export (eg: backup restores).
>
Exactly. Also for my current project, these files may end up in the hands
of users (GDPR requires user access to data in structured formats, so it
will be a win to have a standard that everyone can use). In this instance
it will generally not be known at export time which format is supported by
the destination server (im contrast to an admin performing a migration
between two implementations).
Why is the chronological order of messages in an archive defined as a MUST?
> Does that attempt to safeguard against messages not having a timestamp?
>
Timestamps are not unique. Two messages can have the same timestamp and
order should not be lost.
For better or worse the MAM data model has an ordering that is not visible
in either timestamps or message IDs.
Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] XEP-0227 update
Hi Matt,
Thanks for reviving this thing. It was indeed pretty outdated.
Openfire has an implementation too, although I'm not aware if it was ever
tested against other servers.
Should we consider introducing a change to the namespace as used in the
portable data, to more explicitly handle the changes in format? I'm aware
that you mainly introduced new elements, and the one attribute that you
dropped ('password') is defined as a 'should' - but still: the output is
significantly different. Given the nature of the protocol, it is not
unthinkable that data exported by an implementation following the older XEP
version gets imported by one of a newer version, and vice versa - perhaps
with plenty of time between import and export (eg: backup restores).
Why is the chronological order of messages in an archive defined as a MUST?
Does that attempt to safeguard against messages not having a timestamp?
Kind regards,
Guus
On Wed, 2 Jun 2021 at 18:00, Matthew Wild wrote:
> Hi folks,
>
> This somewhat forgotten XEP used to be the way to migrate data between
> XMPP services. Unfortunately it didn't keep up with the times, and
> many servers gained tools for importing directly from the native
> formats of other servers (Prosody has an ejabberd importer, ejabberd
> has a Prosody importer).
>
> Even if it never again becomes the standard format for server software
> migrations (XML is not an ideal format when you're dealing with
> massive amounts of data), as part of the XMPP account portability
> project[1] I want to once again bring XEP-0227 up to date with what
> data commonly constitutes an XMPP account.
>
> I've prepared an update that adds some of the missing features:
>
> - SCRAM hashes (it previously recommended inclusion of plaintext
> passwords)
> - PEP nodes (configuration and items)
> - Message archives
>
> I'd appreciate feedback, and also I'd be curious of any wishlist items
> that anyone else may have.
>
> The draft PR is at: https://github.com/xsf/xeps/pull/1064 and a
> rendered version is available at
> https://matthewwild.co.uk/uploads/xeps/xep-0227.html
>
> Regards,
> Matthew
>
> [1]: https://docs.modernxmpp.org/projects/portability/
> ___
> 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
___
[Standards] XEP-0227 update
Hi folks, This somewhat forgotten XEP used to be the way to migrate data between XMPP services. Unfortunately it didn't keep up with the times, and many servers gained tools for importing directly from the native formats of other servers (Prosody has an ejabberd importer, ejabberd has a Prosody importer). Even if it never again becomes the standard format for server software migrations (XML is not an ideal format when you're dealing with massive amounts of data), as part of the XMPP account portability project[1] I want to once again bring XEP-0227 up to date with what data commonly constitutes an XMPP account. I've prepared an update that adds some of the missing features: - SCRAM hashes (it previously recommended inclusion of plaintext passwords) - PEP nodes (configuration and items) - Message archives I'd appreciate feedback, and also I'd be curious of any wishlist items that anyone else may have. The draft PR is at: https://github.com/xsf/xeps/pull/1064 and a rendered version is available at https://matthewwild.co.uk/uploads/xeps/xep-0227.html Regards, Matthew [1]: https://docs.modernxmpp.org/projects/portability/ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
