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

[Lance Stout]

An additional reference from XEP-0301 (In-Band Real Time Text) in support of 
this:

https://xmpp.org/extensions/xep-0301.html#unicode_character_counting



> On Dec 17, 2019, at 3:18 AM, p...@bouah.net wrote:
> 
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Character counting in message bodies
> Abstract:
> This document describes how to correctly count characters in message
> bodies. This is required when referencing a position in the body.
> 
> URL: https://xmpp.org/extensions/inbox/charcount.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 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 Dienstag, 17. Dezember 2019 12:18:53 CET p...@bouah.net wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Character counting in message bodies
> Abstract:
> This document describes how to correctly count characters in message
> bodies. This is required when referencing a position in the body.
> 
> URL: https://xmpp.org/extensions/inbox/charcount.html
> 
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.

I am firmly +1 on this.

The only thing I consider worth adding is a note that codepoints are the 
foundation of XML and thus match the XML data model nicely, which is another 
point in favour of using them.

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
___

[Standards] XMPP Council Agenda for 2019-12-18

[Jonas Schäfer]

Hi everyone,

The next XMPP Council Meeting will take place on 2019-12-18 at 16:00Z in 
xmpp:coun...@muc.xmpp.org?join. Everyone is welcome to join and give comments.

This agenda is composed from:

- Editor notifications to standards@
- xsf/xeps GitHub PRs 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) Items for voting

3a) Proposed XMPP Extension: Character counting in message bodies

URL: https://xmpp.org/extensions/inbox/charcount.html
Abstract: This document describes how to correctly count characters in message 
bodies. This is required when referencing a position in the body. 

4) Outstanding Votes

4a) Votes on Ressurection of Reactions

5) Date of Next

6) AOB

7) Close

End of Agenda.

Note that I am aiming for 30 minutes.

Meetings are normally held every Wednesday at 1600 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.

You can join anonymously using your Browser at https://xmpp.`org/chat?council 
.

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

I aim to publish the Agenda at the day before the Council meeting before 
20:00Z.


Thanks everyone,
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: Message Fastening

[Jonas Schäfer]

(lots of snipping going on, comment inline)

On Donnerstag, 12. Dezember 2019 17:49:20 CET Kevin Smith wrote:
> On 12 Dec 2019, at 15:08, Dave Cridland  wrote:
> > On Thu, 12 Dec 2019 at 12:11, Marvin W  > > wrote: I think the question this comes down to
> > is, what we want to build using fastenings. I don't want reactions to
> > reactions, but if we allow some sort of "comment" as a Fastening, then we
> > should also allow reactions to such comments.
> > 
> > 
> > Interesting - from a syntactic viewpoint, you're absolutely right. But I
> > think you're entirely wrong from a protocol behaviour standpoint. So I
> > wonder if there's a distinction to be made between various kinds of
> > relationship:
> > 
> > * […]
> > 
> > * […]
> > 
> > * Messages where the content relates to another. Comments, threading,
> > replies, etc are all closely related to another message, but they're
> > clearly a message in their own right. A degradation here might involve
> > losing the relationship rather than the message.
> > 
> > I think Fastenings really only cover the first - MAM would here provide a
> > summary view of any fastenings. MAM doesn't urgently need to support the
> > last case at all. The middle case is somewhat harder - we might want to
> > have MAM aware of these but it would need to collate these in full - and
> > perhaps it even provides a unified view of a message and its edits etc?
> > 
> > As a thought experiment, it'd be interesting to ask:
> > 
> > 1) Are there any other "buckets" of message relationship types?
> > 
> > 2) What existing relationships fit into what types?
> > 
> > 3) What typical behaviours do we want to see (and thus support) on the
> > clients?
> 
> […]
> 
> 3) summary=‘urn:xmpp:fastening:none:0': 
> Where the new message is a new message in its own right, but that has some
> sort of link to a previous one. e.g. Comments (I’m not convinced that this
> is the right way to be doing comments, but if we did, like this). These can
> have their own fastenings. ‘Messages where the content relates to another’
> from Dave’s list.

The third case deviates a lot from the original intent of Fastening (e.g. by 
allowing recursion) and covers cases for which we’re very far from having 
proper UX.

I suggest to omit this use case from fastening if you ever get to the point 
where it would complicate matters (e.g. business rules w.r.t. recursive 
fastenings).


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: Message Fastening

[Jonas Schäfer]

On Mittwoch, 11. Dezember 2019 18:10:32 CET Kevin Smith wrote:
> > The  element should always state the QName of the external
> > element. I suggest we normalize the namespace of , and the other
> > few elements that carry multiple namespaces, to jabber:client.
> 
> I’ll go along with the majority here if more people provide feedback.

What exactly is a QName? prefix:foo? I find the syntax currently proposed by 
Fastening better in that it doesn’t require to carry state about the XML tree 
beyond the XML parser.

In any case, the namespace should *always* be explicitly specified with the 
normalisation suggested by Florian (i.e. treat jabber:server and jabber:client 
as equivalent and normalise them to jabber:client).

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

[Kevin Smith]

I don’t have feedback to give at the moment, but this is a thing we’ve needed 
for a long time, so a big thank you to Marvin for getting something submitted.

/K

> On 17 Dec 2019, at 11:18, p...@bouah.net wrote:
> 
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Character counting in message bodies
> Abstract:
> This document describes how to correctly count characters in message
> bodies. This is required when referencing a position in the body.
> 
> URL: https://xmpp.org/extensions/inbox/charcount.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 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

[Guus der Kinderen]

This XEP might want to add an implementation note that relates to
https://xmpp.org/extensions/xep-0245.html. When XEP-0245 is used, clients
often use a different representation of the message from what's in the body
(eg: replacing "/me" with a nickname). This makes it very easy to make
mistakes in calculating a character-count based offset (eg: to identify the
position of a mention), as a nickname is likely to have a different
character count than the three in "/me". It's kind of a silly problem, but
easy enough to make. Protecting against it by adding it to this XEP can
help.

On Tue, 17 Dec 2019 at 12:20,  wrote:

> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Character counting in message bodies
> Abstract:
> This document describes how to correctly count characters in message
> bodies. This is required when referencing a position in the body.
>
> URL: https://xmpp.org/extensions/inbox/charcount.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 mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[pep]

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

Title: Character counting in message bodies
Abstract:
This document describes how to correctly count characters in message
bodies. This is required when referencing a position in the body.

URL: https://xmpp.org/extensions/inbox/charcount.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] UPDATED: XEP-0422 (Message Fastening)

[pep]

Version 0.1.2 of XEP-0422 (Message Fastening) has been released.

Abstract:
This specification defines a way for payloads on a message to be
marked as being logically fastened to a previous message.

Changelog:
Typographical fixes (ps)

URL: https://xmpp.org/extensions/xep-0422.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] UPDATED: XEP-0284 (Shared XML Editing)

[pep]

Version 0.1.2 of XEP-0284 (Shared XML Editing) has been released.

Abstract:
This specification defines a protocol that enables two or more
endpoints to collaboratively edit an XML object. The protocol is
intended for use mainly over the Extensible Messaging and Presence
Protocol (XMPP), either by existing instant messaging clients or by
specialized editing clients. However, the protocol could also be used
over a direct TCP connection rather than over XMPP.

Changelog:
* Add missing  wrapper in example.
* Fix duplicated new element in example.
* Fix indentation. (egp)

URL: https://xmpp.org/extensions/xep-0284.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] UPDATED: XEP-0328 (JID Preparation and Validation Service)

[pep]

Version 0.2.1 of XEP-0328 (JID Preparation and Validation Service) has
been released.

Abstract:
This specification defines a way for an XMPP entity to request another
entity to prepare and validate a given JID.

Changelog:
Typographical fix. (nv)

URL: https://xmpp.org/extensions/xep-0328.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] UPDATED: XEP-0280 (Message Carbons)

[pep]

Version 0.13.2 of XEP-0280 (Message Carbons) has been released.

Abstract:
In order to keep all IM clients for a user engaged in a conversation,
outbound messages are carbon-copied to all interested resources.

Changelog:
Typographical fix. (sp)

URL: https://xmpp.org/extensions/xep-0280.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
___