dave at cridland.net
Thu Nov 19 11:04:40 UTC 2020
On Wed, 18 Nov 2020 at 20:40, Marvin W <xmpp at larma.de> wrote:
> 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
Your quotation replaces "they were" with "it was"; that has the
unfortunate effect of changing the entire meaning.
I think you intend to alter it as "the message SHOULD be treated as if [the
body element] were not present for most purposes", which makes things
clearer, but as you say that's a naive interpretation anyway. We do indeed
want to display it here if SFS isn't understood. What 428 is trying to do
is allow the client to indicate to the user that the body element is being
shown as a fallback, which isn't adequately captured in that text.
> 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.
What 428 is intending to do is twofold:
* Indicate to clients that if they're just going to display the body tag,
then they are missing something. There was some suggestion - from Georg I
think - that it might be useful to include the XMLNS of the element that
obviates the body.
* Indicate to servers that a message isn't a message at all.
Combining the two is probably unhelpful of me - as I say, I'd have been
happy to use hints, but there was push-back from Council on Hints, so...
As I say, if it's not quite right (and it probably isn't) let's fix it.
> > 2) It uses SFS, but modifies its behaviour with an additional sibling
> > element.
> > 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.
So, where we have - I think - agreement: We should add content disposition
into SFS, which moves the MAY->SHOULD bit into SFS itself. This seems
I don't really follow the logic around not offering to download the
sticker. It's a file. I accept that stickers are not normally individually
downloaded, and there may be copyright issues in taking a (further) copy,
but in terms of interoperability it doesn't seem to make a difference.
> > 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.
I understand and follow what you're saying.
I don't see that this is about interoperability - clients will work
perfectly well to other parties whether or not they ignore this element, so
interoperability is unaffected.
Under copyright law, I think if something ris CC-BY or CC-BY-NC, then the
protocol as written would not be correct as the sticker when sent would
require attribution even if the receiving client only understands SFS.
I don't think the NC applies here, since there doesn't appear to be a way
to monetise the use, let alone make a profit. I see <restricted/> almost
more use for trying to monetise (or the broader "gaining a commercial
advantage" as the wording says).
Finally, it's not entirely clear if sending a sticker or sharing a pack
would contravene the copyright licensing more or less than the recipient
importing the pack and/or saving the sticker.
Anyway, I understand what you're trying to do here at a high level, I just
think it's broadly not going to be useful, and certainly isn't an
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards