Re: [Standards] Stickers

[Dave Cridland]

Sorry, I completely missed this for some reason.

On Thu, 19 Nov 2020 at 15:30, Marvin W  wrote:

> Hi,
>
> On 19.11.20 12:04, Dave Cridland wrote:
> > * 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.
>
> This would indeed by a useful feature, allowing the client to tell the
> users they are displaying the fallback message because they are missing
> a feature. I'd argue that this is also possible without the 
> element, just by noting that there are elements inside the 
> not understood by the client, but having it in a dedicated way and
> thereby signaling that the receiving client misses "something important"
> (and not just lack for support of origin-id, for example) also makes sense.
> However, I'd even go further and argue that such feature is independent
> of body fallback being used or not. E.g. if there was a new type of
> message carrying important information but without a fallback body, I'd
> also want the receiving client to display a note, and not only when
> there is a body.
>
>
We don't, in XMPP, have critical extensions, like LDAP (Or X.400/X.500 in
general). I think that's OK - if an entity sends a stanza that the
recipient cannot understand at all, that is nevertheless critical, then
something has gone wrong in service discovery.

But for the rest, yes. Do we want the fallback element to have "the XMLNS
of the extension", or does it make more sense to have the feature "var"
that would be used in Disco? (I lean toward the latter).


> > * Indicate to servers that a message isn't a message at all.
>
> And here we totally disagree. A sticker message is a message for all
> purposes the server should care. Consider a sticker a "glorified emoji".
> Most users would fallback to send the emoji as text instead of a sticker
> if the sending client had no sticker support.
> Also the fallback is not only a "legacy compatibility fallback", but
> also a "technically not possible fallback". For example, when Telegram
> receives a sticker it creates a notification with only the "base" emoji,
> because notifications on many platforms can't carry images (and/or using
> the image feature in notifications for stickers would maybe be
> inappropriate).
>
>
OK, I think you're persuading me here. I think we may need to revisit hints
for the server-side though.


> Maybe we should note that there are two types of fallback bodies:
> - "Approximating fallbacks": The body contains a text that closely
> approximates the intended message, but lacks some features that would
> normally be there, e.g. interactivity, inline media, etc. Both stickers
> and SFS fall in this category. The general assumption for those is that
> it is better to behave as if the message was just a "simple" message
> with that body instead of e.g. displaying an error to the user.
> - "Incompatibility warning fallback": The body just notifies that
> important information is not available because the receiving entity does
> not support a certain XEP. An example for this would be encryption XEPs,
> (which have XEP-0380 to indicate this).
>
>
Yes, '380 works if you understand encryption (or at least the concept), but
not this instance of it.

I like the notion of "this is a degraded version of the extended message"
versus "this wasn't really a message at all, this message explains why".
The latter feels like a case of failed feature negotiation, though.


> > 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.
>
> What I wanted to express is that in the case of stickers, the sender
> would prefer the recipient to see the fallback body (e.g. the emoji
> showing the same emotion as the sticker) instead of a download button,
> if for some reason the recipient does not support displaying the file
> inline. Remember that stickers are typically used as an alternative to
> emojis. Even if it's technically a file and no text anymore, it makes no
> sense to download the file, just as you don't have a "Save message to
> file" option in a typical instant messenger.
>
>
Yup, that all makes sense.


> > 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.
>
> I'm happy to change respective wording from uppercase to lowercase to
> ensure it's not perceived as an RFC2119 keyword.


Well, now, that's an entirely new can of worms.

There's been some confusion over whether lower-cased "should" counts as RFC
2119. A handful of people in the IETF thought it did, or at least might,
and so there was anoth

[Standards] RFC 2119 boilerplate in XEPs

[Florian Schmaus]

On 12/8/20 9:40 AM, Dave Cridland wrote:

Sorry, I completely missed this for some reason.
On Thu, 19 Nov 2020 at 15:30, Marvin W > wrote:

 > 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.

I'm happy to change respective wording from uppercase to lowercase to
ensure it's not perceived as an RFC2119 keyword.


Well, now, that's an entirely new can of worms.

There's been some confusion over whether lower-cased "should" counts as 
RFC 2119. A handful of people in the IETF thought it did, or at least 
might, and so there was another BCP created to say that only upper-cased 
SHOULD counts. The XSF hasn't been able to adopt this because it is 
thought by some that existing XEPs might use a lower-cased "should" in 
the sense of RFC 2119's SHOULD.


The RFC 2119 reference is part of our generalised boilerplate, so we 
have to switch wholesale, which means isolating each instance of a 
case-insensitive RFC 2119 keyword and "fixing" it first.


I do not think it is necessarily true that we "have to switch 
wholesale". We could introduce a new revision of the boilerplate text, 
which refers to RFC 8174, that is used by new XEPs, while the existing 
XEPs continue to refer solely RFC 2119. Or am I missing something?


- Florian



OpenPGP_signature
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Stickers

[Kevin Smith]

Just to focus on a tiny bit of this...

> On 8 Dec 2020, at 08:40, Dave Cridland  wrote:
>  "this wasn't really a message at all, this message explains why". The latter 
> feels like a case of failed feature negotiation, though.

I think we used to believe that. In the face of carbons and MAM, I it’s no 
longer true (and maybe it never was).

/K___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Stickers

[Dave Cridland]

On Tue, 8 Dec 2020 at 09:25, Kevin Smith  wrote:

> Just to focus on a tiny bit of this...
>
> On 8 Dec 2020, at 08:40, Dave Cridland  wrote:
>  "this wasn't really a message at all, this message explains why". The
> latter feels like a case of failed feature negotiation, though.
>
>
> I think we used to believe that. In the face of carbons and MAM, I it’s no
> longer true (and maybe it never was).
>

It's still a failure even if there's no good way to do it for now.

Either way, I think we do need a better story around this failure case, and
a way of reducing the failure case.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] UPDATED: XEP-0372 (References)

[XEP Editor Pipeline]

Version 0.4.0 of XEP-0372 (References) has been released.

Abstract:
This document defines a method for one XMPP stanza to provide
references to another entity, such as mentioning users, HTTP
resources, or other XMPP resources.

Changelog:
Specify that begin is inclusive, starts counting at zero, and that end
is exclusive (Dijkstra-based convention) (gh/jcbrand)

URL: https://xmpp.org/extensions/xep-0372.html

Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Proposed XMPP Extension: Stanza Multiplexing

[XEP Editor Pipeline]

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: Stanza Multiplexing
Abstract:
This spec provides a mechanism for multiplexing multiple virtual hosts
over a single XMPP session.

URL: https://xmpp.org/extensions/inbox/mux.html

The Council will decide in the next two weeks whether to accept this
proposal as an official XEP.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XMPP Council Agenda 2020-12-09

[Jonas Schäfer]

Hi everyone,

The next XMPP Council Meeting will take place on 2020-12-09 at 16:00Z in 
xmpp:coun...@muc.xmpp.org?join. Everyone is welcome to join and add to the 
discussions.

This agenda is composed from:

- Editor notifications to standards@
- xsf/xeps GitHub PRs marked as Needs Council
- xsf/xeps GitLab MRs marked as Needs Council
- Suggestions directly sent to me (see below)

Agenda as follows:

1) Roll Call

2) Agenda Bashing

* Feel free to pre-bash on-list or directly to me if you think something is 
missing.

3) Editor’s Update

* New ProtoXEP: Stanza Multiplexing

4) Items for voting

4a) Proposed XMPP Extension: Stanza Multiplexing
URL: https://xmpp.org/extensions/inbox/mux.html
Abstract: This spec provides a mechanism for multiplexing multiple virtual 
hosts over a single XMPP session. 

5) Pending Votes

- Everyone got some, please check last week’s agenda/minutes.

6) Date of Next

7) AOB

8) Close

End of Agenda.

Note that I am aiming for 30 minutes, but meetings may be extended as 
necessary if all council members agree.

Meetings are normally held every Wednesday at 16:00 UTC in the
xmpp:coun...@muc.xmpp.org?join chatroom.
Meetings are open, and anyone (XSF Member or not) may attend, though only XMPP 
Council members may vote. Relevant comments from the floor are welcomed.

Using your web browser, you can join anonymously via
https://xmpp.org/chat?council

Note that conversations in the room are logged publicly at
https://logs.xmpp.org/council/

If you have suggestions for an agenda item, you can message me via XMPP or 
email at this address or at jo...@zombofant.net.

I aim to publish the Agenda on the day before the Council meeting before 
19:00Z.

Stay safe, smart & healthy,
Jonas


signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

[Jonas Schäfer]

On Freitag, 4. Dezember 2020 21:33:38 CET Sam Whited wrote:
> On Fri, Dec 4, 2020, at 20:23, Florian Schmaus wrote:
> > I begin to feel that a lot of your rationale is based on the idea that
> > you always (/often?) have access to the raw UTF-8 bytes as they
> > appeared on the wire.
> 
> Yes, most of it is.
> 
> > While is is probably true for languages where the String type's native
> > encoding is also UTF-8. It is usually not true for others. For
> > example, widely used XML parser in Java will return Java's String
> > type, which is UTF-16 (or ISO-8859-1 [1]) based.
> 
> Yes, this is fair, I was thinking you could probably always get the raw
> bytes, but it does look like a lot of these *only* do DOM based parsing
> and don't keep the original representation.

This has nothing to do with DOM vs. whatever. SAX can also give you the data 
in the format which is described by the XML model (code points).

So it appears there are two sides and arguing from the point of view of 
programming languages will give us always those who get the raw representation 
of the data on the wire (C-ish things) and those who get the high-level 
representation.

Thus, I propose that we stick with what the standards offer. XMPP is based on 
XML in that all data exchanged is somehow wrapped in XML. XML specifies that 
all character data (text) is a sequence of unicode code points. The encoding 
on the wire is irrelevant after decoding of XML; on the *abstract* layer, XML 
provides sequences of code points, nothing else. 

Some libraries always convert to UTF-8 (libxml2), some bindings always offer 
some kind of unicode codepoints (e.g. python which opportunistically chooses 
ASCII/UCS-2/UCS-4 depending on the data), some bindings may even expose the 
raw bytes and let the user deal with it (I think there was/is a zero-copy 
implementation which mostly consisted of strategically replacing XML 
metacharacters with NUL bytes in the incoming data).

But all implementations which want to be XMPP and XML 1.0 compliant need to 
have some way to convert or offer access to code points, as that’s the XML data 
model. Let’s build on that.

Easy choice.

Much easier than writing 20 emails on this topic, and that just in this 
thread.

> > However, given that there is a wide variety here, I am not sure if it
> > is worth to take any of that into consideration.
> 
> Yes, fair enough.
> 
> > Instead, my rationale is based on the idea that you always have
> > access to the Unicode code points of the textual content obtained
> > from the XML.
> 
> I do not have that access without converting from UTF-8 to code points
> in the hot-path where it would be inappropriate. It's effectively the
> same thing: I don't want to convert from bytes to code points, you don't
> want to convert from codepoints to bytes. Some languages will have to do
> the conversion either way, so it seems worth using the thing that allows
> for the most flexibility with the least amount of work in eg. IoT
> devices using C that are trying to optimize for performance where
> passing along the bytes as received on the wire (possibly with some
> validation that the range is accurate) is acceptable.

Note that you do not have to decode UTF-8 (which can be between O(n) and 
O(n^2) depending on the implementation and circumstances) to count code 
points; you can certainly do the counting in O(n) (which is the same as 
strlen() in C). And it would be similarly easy to write algorithms to do 
efficient batched codepoint indexed operations on UTF-8 strings in C (such as 
splitting UTF-8 byte ranges based on start/end information or such), if you 
really wanted to do such things in C.

However, I also think that the IoT use-case is a bit strawmanny, given that 
IoT devices would rarely have to deal with markup or other rich human-facing 
formats which require decoding of such codepoint references.

Thus ... I don’t buy this argument. Devices which render markup or references 
would have to deal with complexity way beyond this. And they’ll have to do the 
decoding anyway to do some kind of text rendering.

kind regards,
Jonas

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

[Sam Whited]

The XML library I use does not give me a string or slice of code points,
it gives me a slice of bytes because that's the level I'm operating at.
Even at the higher level if I decode the bytes into a string (A Go
string in this case), that is still just a slice of UTF-8 bytes (it does
not decode them, ensure they're valid, and turn them into a slice of
code points, that is a very expensive operation that it avoids until you
need it or explicitly do it yourself).

I don't understand how this is part of the XML data model. Do you mean
that only Unicode encodings are supported by XML? If so, that's fair and
removes one of my arguments, I did not know that was the case. However,
I still think the data on the wire should describe the other data on the
wire, not some higher- level "decoded" representation that many XML
libraries may not even use.

—Sam

On Tue, Dec 8, 2020, at 21:32, Jonas Schäfer wrote:
> But all implementations which want to be XMPP and XML 1.0 compliant
> need to have some way to convert or offer access to code points, as
> that’s the XML data model. Let’s build on that.
>
> Easy choice.
>
> Much easier than writing 20 emails on this topic, and that just in
> this thread.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Character counting in message bodies

[Kevin Smith]

On 8 Dec 2020, at 22:13, Sam Whited  wrote:
> I still think the data on the wire should describe the other data on the
> wire, not some higher- level "decoded” representation

Agree 100%. References et al. need to calculate how the data are going to be 
encoded on the wire, not some high level abstraction. Decoding TLS is very 
expensive and I shouldn’t have to do that before I’m able to work out what the 
text being referenced is.

;)

/K



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___