On Wed, 18 Nov 2020 at 20:40, Marvin W <x...@larma.de> wrote: > Hi, > > 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. > > 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 > display. > > 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 generically useful. 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 interoperability concern. > Marvin > _______________________________________________ > 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 _______________________________________________
