* Jonas Schäfer [2021-03-24 17:03]:
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
Yes.
> 2. Does the specification solve the problem stated in the introduction
> and requirements?
Yes.
> 3. Do you plan to implement this specific
On Wed, Mar 24, 2021 at 04:02:09PM -, Jonas Schäfer wrote:
This message constitutes notice of a Last Call for comments on
XEP-0280.
Title: Message Carbons
Abstract:
In order to keep all IM clients for a user engaged in a conversation,
outbound messages are carbon-copied to all interested res
> On 24 Mar 2021, at 16:02, Jonas Schäfer (XSF Editor)
> wrote:
>
> This message constitutes notice of a Last Call for comments on
> XEP-0280.
>
> Title: Message Carbons
> Abstract:
> In order to keep all IM clients for a user engaged in a conversation,
> outbound messages are carbon-copied t
On Wed, 24 Mar 2021 at 16:02, Jonas Schäfer wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0280.
>
> Title: Message Carbons
> Abstract:
> In order to keep all IM clients for a user engaged in a conversation,
> outbound messages are carbon-copied to all interested re
This message constitutes notice of a Last Call for comments on
XEP-0280.
Title: Message Carbons
Abstract:
In order to keep all IM clients for a user engaged in a conversation,
outbound messages are carbon-copied to all interested resources.
URL: https://xmpp.org/extensions/xep-0280.html
This Las
* Ruslan N. Marchenko [2020-07-14 23:52]:
> The sections 7 & 8 are referring to RFC 6121 for message delivery and
> mentions the CC should be after delivery. In 7 kind of implicitly, in 8
> ambiguous, 'and' could mean 'and then' or 'and also'. The question is -
> what happens for unsuccessful deli
Am Dienstag, den 31.03.2020, 20:38 + schrieb Jonas Schäfer:
> This message constitutes notice of a Last Call for comments on
> XEP-0280.
>
> Title: Message Carbons
> Abstract:
> In order to keep all IM clients for a user engaged in a conversation,
> outbound messages are carbon-copied to all i
This message constitutes notice of a Last Call for comments on
XEP-0280.
Title: Message Carbons
Abstract:
In order to keep all IM clients for a user engaged in a conversation,
outbound messages are carbon-copied to all interested resources.
URL: https://xmpp.org/extensions/xep-0280.html
This Las
* Jonas Schäfer [2019-01-08 17:55]:
> This message constitutes notice of a Last Call for comments on
> XEP-0280.
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
Yes, it is a very important piece for modern multi-client deployments
On Tue, 8 Jan 2019 at 16:54, Jonas Schäfer wrote:
> This message constitutes notice of a Last Call for comments on
> XEP-0280.
>
> Title: Message Carbons
> Abstract:
> In order to keep all IM clients for a user engaged in a conversation,
> outbound messages are carbon-copied to all interested res
This message constitutes notice of a Last Call for comments on
XEP-0280.
Title: Message Carbons
Abstract:
In order to keep all IM clients for a user engaged in a conversation,
outbound messages are carbon-copied to all interested resources.
URL: https://xmpp.org/extensions/xep-0280.html
This Las
Not 100% sure if relevant, but I'll remind of my request for
clarification I've posted here just in case:
As far as I can see, nothing in the XEP prohibits carbons from being
generated by outside sources (granted that other conditions are
satisifed). Carbons can only be sent from the user's bare
This message constitutes notice of a Last Call for comments on
XEP-0280.
Title: Message Carbons
Abstract:
In order to keep all IM clients for a user engaged in a conversation,
outbound messages are carbon-copied to all interested resources.
URL: https://xmpp.org/extensions/xep-0280.html
This Las
On Wed, Feb 8, 2017 at 5:07 PM, XMPP Extensions Editor wrote:
> This message constitutes notice of a Last Call for comments on XEP-0280
> (Message Carbons).
Since there is still open discussion and pending changes to this XEP,
I have extended the LC until 2017-03-28.
—Sam
__
On 23.02.2017 08:36, Sam Whited wrote:
I *think* I'm against continuing to reference 0334 here. While this
hint is theoretically useful for other specs (eg. if there were some
kind of pubsub-MAM-sync in the future that replaced carbons), I'm not
sure we need to try and make it that reusable, and
On Thu, Feb 16, 2017 at 11:02 AM, Georg Lukas wrote:
> My personal stance would be: discard , reference 334, be done
> with it. However, that would probably require a namespace bump.
I *think* I'm against continuing to reference 0334 here. While this
hint is theoretically useful for other specs (
* XMPP Extensions Editor [2017-02-09 00:07]:
> This Last Call begins today and shall end at the close of business on
> 2017-02-22.
As outlined in the "Carbon Rules for MUC-PMs" mail[0], here are two PRs
against 0045 and 0280:
https://github.com/xsf/xeps/pull/436 "XEP-0045: Add tag to MUC-PMs"
* Matthew A. Miller [2017-02-16 18:31]:
> About the only argument I'm aware of for keeping it is existing
> implementations. If the namespace version bumps, that kind of
> "solves" that problem.
I really don't like bumping, but as this is a privacy-sensitive matter,
I think we really need to do
> On Feb 16, 2017, at 10:28, Peter Saint-Andre wrote:
>
> On 2/16/17 10:02 AM, Georg Lukas wrote:
>> * Ruslan N. Marchenko [2017-02-13 19:30]:
As there was no consensus two years ago, I just added both elements to
0280 in https://github.com/xsf/xeps/pull/382
>>>
>>> Thanks for clarifi
On 2/16/17 10:02 AM, Georg Lukas wrote:
* Ruslan N. Marchenko [2017-02-13 19:30]:
As there was no consensus two years ago, I just added both elements to
0280 in https://github.com/xsf/xeps/pull/382
Thanks for clarification, but then still, why two? if is still
required to avoid bump, why not
* Ruslan N. Marchenko [2017-02-13 19:30]:
> >As there was no consensus two years ago, I just added both elements to
> >0280 in https://github.com/xsf/xeps/pull/382
>
> Thanks for clarification, but then still, why two? if is still
> required to avoid bump, why not to stick to that? Especially if,
On 13.02.2017 15:29, Georg Lukas wrote:
* Ruslan N. Marchenko [2017-02-12 16:33]:
No, the no-copy use is ambiguous. Are private and no-copy equivalent? Are
they complementing each other? what is the server behaviour when only one of
them is provided?
I personally am in favour of order for own
* Ruslan N. Marchenko [2017-02-12 16:33]:
> No, the no-copy use is ambiguous. Are private and no-copy equivalent? Are
> they complementing each other? what is the server behaviour when only one of
> them is provided?
> I personally am in favour of order for owner and no-copy hint for
> remote par
* XMPP Extensions Editor [2017-02-09 00:07]:
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to
> clarify an existing protocol?
yes
> 2. Does the specification solve the problem stated in the introduction and
> requirements?
yes, to approximately 90%. The last bul
On 09.02.2017 00:07, XMPP Extensions Editor wrote:
This message constitutes notice of a Last Call for comments on XEP-0280
(Message Carbons).
Abstract: In order to keep all IM clients for a user engaged in a conversation,
outbound messages are carbon-copied to all interested resources.
URL:
On 09.02.2017 00:07, XMPP Extensions Editor wrote:
> This message constitutes notice of a Last Call for comments on XEP-0280
> (Message Carbons).
>
> Abstract: In order to keep all IM clients for a user engaged in a
> conversation, outbound messages are carbon-copied to all interested resources.
This message constitutes notice of a Last Call for comments on XEP-0280
(Message Carbons).
Abstract: In order to keep all IM clients for a user engaged in a conversation,
outbound messages are carbon-copied to all interested resources.
URL: http://xmpp.org/extensions/xep-0280.html
This Last Ca
On 23 Jun 2016, at 15:02, Sam Whited wrote:
>
> On Thu, Jun 23, 2016 at 2:49 AM, Florian Schmaus wrote:
>> I also still think that we should clarify somewhere if the carbons state
>> is kept after a stream resumption or not [1]. Not sure if the right
>> place for this would be xep280 or xep198.
On Thu, Jun 23, 2016 at 2:49 AM, Florian Schmaus wrote:
> I also still think that we should clarify somewhere if the carbons state
> is kept after a stream resumption or not [1]. Not sure if the right
> place for this would be xep280 or xep198.
I think the place for this is in Stream Management (
On 22.06.2016 18:16, Peter Saint-Andre wrote:
> On 6/22/16 10:06 AM, Georg Lukas wrote:
>> * Peter Saint-Andre [2016-06-22 17:44]:
>>>A is not eligible for carbons delivery if it is
>>>determined to have been sent by a MUC room or service, even if it
>>>would be otherwise eligible (th
On 6/22/16 10:06 AM, Georg Lukas wrote:
* Peter Saint-Andre [2016-06-22 17:44]:
A is not eligible for carbons delivery if it is
determined to have been sent by a MUC room or service, even if it
would be otherwise eligible (this also includes private messages
from MUC participants).
* Peter Saint-Andre [2016-06-22 17:44]:
>A is not eligible for carbons delivery if it is
>determined to have been sent by a MUC room or service, even if it
>would be otherwise eligible (this also includes private messages
>from MUC participants).
IMHO, this rule is more relevant
On Wed, Jun 22, 2016 at 5:42 PM, Peter Saint-Andre
wrote:
> 2. Given the widespread deployment of messaging services that are centered
> on groupchat (e.g., Slack and HipChat), it seems shortsighted to specify
> this rule:
>
>A is not eligible for carbons delivery if it is
>determined to
On 6/14/16 7:26 AM, Kim Alvefur wrote:
On 2015-08-13 22:18, XMPP Extensions Editor wrote:
This message constitutes notice of a Last Call for comments on XEP-0280
(Message Carbons).
Friendly inquiry regarding the status of this LC.
The Council is voting. In fact, all of the other Council mem
On 2015-08-13 22:18, XMPP Extensions Editor wrote:
> This message constitutes notice of a Last Call for comments on XEP-0280
> (Message Carbons).
Friendly inquiry regarding the status of this LC.
--
Kim "Zash" Alvefur
signature.asc
Description: OpenPGP digital signature
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to
> clarify an existing protocol?
While I think there is a gap in the XMPP specifications in ways for allowing a
user to transparently switch clients in mid-conversation, it’s seems this spec
inadequately addresses th
On 13.08.2015 22:18, XMPP Extensions Editor wrote:
> This message constitutes notice of a Last Call for comments on XEP-0280
> (Message Carbons).
>
> Abstract: In order to keep all IM clients for a user engaged in a
> conversation, outbound messages are carbon-copied to all interested resources.
On 18 Aug 2015, at 12:57, Kurt Zeilenga wrote:
> Are we being asked to comment on this XEP with or without the pending PRs
> applied?
Technically, it should be on the published version of 280. However, given that
there are pending PRs reflecting what seems to be community concensus (and that
a
Are we being asked to comment on this XEP with or without the pending PRs
applied?
— Kurt
> On Aug 13, 2015, at 1:18 PM, XMPP Extensions Editor wrote:
>
> This message constitutes notice of a Last Call for comments on XEP-0280
> (Message Carbons).
>
> Abstract: In order to keep all IM client
This message constitutes notice of a Last Call for comments on XEP-0280
(Message Carbons).
Abstract: In order to keep all IM clients for a user engaged in a conversation,
outbound messages are carbon-copied to all interested resources.
URL: http://xmpp.org/extensions/xep-0280.html
This Last Ca
40 matches
Mail list logo
