[Standards] XEP-0280: <private/> vs. <no-copy/>

Florian Schmaus flo at geekplace.eu
Tue Sep 29 15:02:03 UTC 2015

On 17.09.2015 13:31, Christian Schudt wrote:
> Hi,
>> I get your point. But it feels wrong to define nearly identical
>> extension elements in two XEPs. The author of xep334, Matthew Wild,
>> already expressed his willingness to change xep334 so that it can be
>> re-used in xep280. Therefore I'm all for changing xep334, then issue a
>> last call for it, ideally advance it to draft, then issue another last
>> call for a xep280 version using xep334 elements, and finally advance it
>> to draft.
> Speaking of reusing: Why not just re-use XEP-0079 here?

Good point. After reviewing AMP (xep79), it appears to be well designed
in a modular fashion. This would mean that server developers wouldn't
need to implement all of it, just the required parts to achieve what
xep334 does. Please correct me if I'm wrong.

> http://xmpp.org/extensions/xep-0079.html#description-match-resource
> action="drop" value="other" should do the same as <no-copy/> or <private/>.
> In general XEP-0334 seems to have overlapping parts with XEP-0079, e.g. <no-store/> vs.
> action="drop" value="stored".
> Actually I am in favor for not having two XEPs with the same use cases.

While I was first an advocate for using xep334 in xep280, it appears
that using xep79 provides a good alternative.

I've heard multiple times, including from one of the authors of AMP,
that AMP was a mistake. Could somebody elaborate on that? What is wrong
with it? I knew it existed, but didn't discovered until now that it's
modular (see Example 4). Hence the usual flaw of large specifications,
that you potentially need to implement all of it just to get a certain
feature, doesn't apply.

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150929/9dc2d99b/attachment.sig>

More information about the Standards mailing list