xmpp at larma.de
Wed Nov 18 20:39:17 UTC 2020
On 18.11.20 18:08, Dave Cridland wrote:
> 1) Use of fallback body
> I really dislike this as a general mechanism, but at least let's mark it
> using XEP-0428 (and if that's not quite right, let's fix it).
I was under the assumption that marking fallbacks using XEP-0428 is a
thing described in XEP-0428 and not to be repeated in every XEP.
Beside that, I also don't think that XEP-0428 applies here. It describes
that if <fallback/> is present, clients are allowed "to ignore (and not
display) the content" of <body/> and that "the message SHOULD be treated
as if [it was] not present for most purposes". This is exactly not the case.
The fallback body should be treated as if it was present for all
purposes *except when the processing entity supports SFS*. If the
processing entity supports SFS, it already knows that the body is only
for fallback purposes and thus <fallback/> would not add any value. I
personally think this applies to most usages of fallback bodies (which
would render XEP-0428 rather useless), but I guess there are some usages
where it isn't.
I mostly understood XEP-0428 as a "more descriptive" way of <no-store/>
hint (which is also what §2.3 of the XEP itself basically says). In case
of SFS, it's exactly the opposite: adding a <store/> hint when no
fallback body is present would be appropriate.
> 2) It uses SFS, but modifies its behaviour with an additional sibling
> This has some really odd behaviour to naive clients - a client
> supporting SFS but not stickers will show a downloadable file, which is
> exactly not what you want here.
SFS states "If the <media-type/> of the shared file is such that it can
be displayed inline, the receiving entity MAY display the file inline."
Stickers basically changes this MAY to a SHOULD. A content disposition
field could do exactly the same but would be directly a part of SFS.
However the behavior in the case of where the receiving entity decides
to not display the sticker (e.g. when inline display is not possible for
technical reason) would still need to be derived from the Stickers spec
and not SFS: Stickers should not be offered for download at all whereas
normal SFS should be offered for download when not supported for inline
Of course this could be somehow encoded into SFS as well, e.g. adding
something like `<inline fallback="body" />`.
However I'm tempted to say that this seems more like something for a
separate extension to SFS and not the spec itself. If such an extension
would be written, it definitely would make sense to have stickers adopt it.
> 3) The <restricted/> element is weird.
The motivation of the restricted element is indeed mostly derived from
legal/licensing. However it still is about interoperability. The
motivation is to simplify around licensing, until a better solution is
found to describe the license more detailed. If a more detailed license
description is provided outside of the current protocol and that
description as understood by the client allows importing, the sticker
pack may still be imported.
Just to make an example:
- If a sticker pack is under CC-BY, it can be freely copied for as long
as the license and copyright owner is in the summary field of the
sticker pack. It thus will not put a restricted element in place.
- If a sticker pack is under CC-BY-NC, it cannot be freely copied,
because XMPP can be used commercially. Thus a restricted element is
added and receiving clients are not supposed to allow importing. A
future XEP or update might describe a way to tell that the restriction
is put in place because of the non-commercial rule of CC-BY-NC license.
If a receiving client understands this description and knows that it
acts non-commercial (e.g. by asking the user), it can then allow importing.
More information about the Standards