Hi,
Thanks for your feedback!
On Wed, 23 Jun 2021, 17:21 Guus der Kinderen, <guus.der.kinde...@gmail.com>
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
_______________________________________________
