Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Georg Lukas]

* 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 specification in your code? If not,
> why not?

Implemented in yaxim since ~2013.

> 4. Do you have any security concerns related to this specification?

Given the number of CVEs this specification has accumulated, I think we
need a Huge Red Blinking Marquee tag in our stylesheet to introduce the
security section.

> 5. Is the specification accurate and clearly written?

Mostly yes. I have some minor things that I'd like to address after the
LC though, for which I'm interested in public feedback.


0. Mandatory Rules Support

The result of the last Last Call was the introduction of the Recommended
Rules (§6.1) and a feature flag for their mandatory support (§6.2)
roughly two years ago. It looks like only ejabberd so far has started
advertising the "urn:xmpp:carbons:rules:0" feature.

I'd really like to see more feedback from server developers on this new
part of the specification.


1. Bridge Carbons: this is a verbatim copy from my 2019 Last Call
response:

When you have a bridge to a legacy network, you want to see the messages
sent from your legacy client in your XMPP client, so you need some way
to whitelist the bridge to send you 'sent' (and 'received'?) carbons
with user JIDs behind that bridge. This is in violation of XEP-0280
Security Rules, but would be still very useful. "XEP-0356: Privileged
Entity" or "XEP-0321: Remote Roster Management" might be a solution to
that.

Related thread:
https://mail.jabber.org/pipermail/standards/2018-January/034224.html


2. Message Hints

XEP-0334 ended up in Abandoned state and there is no clear way forward
with it. Carbons is still using Hints as one of two signalling
mechanisms, which is not very pretty, but also not harmful.

With the long-term future of Hints being unclear, I'm not sure if it is
good to keep it in Carbons, or to make some wasel-wording that the
server must accept either as a signal to not carbon-copy.

Reltated thread:
https://mail.jabber.org/pipermail/standards/2017-June/032847.html


3. Stripping of the  element

I agree with Kev that the receiving server should not remove the private
element, and it would be good to have a Council discussion of the
implications of removing the removal requirement.


4. Mobile Considerations

I think the mobile considerations have it all backward; Carbons are
especially important for mobile clients and we should strongly encourage
them to implement it.


5. Messages to Self

When you send a message to your own JID, you'll end up with multiple
copies, see
https://mail.jabber.org/pipermail/standards/2017-March/032421.html

Does it make sense to have a special treatment of these messages in 0280?





Georg


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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Kim Alvefur]

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

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

This Last Call begins today and shall end at the close of business on
2021-04-06.

Please consider the following questions during this Last Call and send
your feedback to the standards@xmpp.org discussion list:

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 specification in your code? If not,
why not?


Started in 2011. Most recently tweaked the rules for which messages are
to be eligible for carbons treatment.


4. Do you have any security concerns related to this specification?


No.


5. Is the specification accurate and clearly written?


Yes, with reservation for not having read the whole thing in its
entirely lately.


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


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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Kevin Smith]

> 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 to all interested resources.
> 
> URL: https://xmpp.org/extensions/xep-0280.html
> 
> This Last Call begins today and shall end at the close of business on
> 2021-04-06.
> 
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
> 
> 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?

It’s probably as good as it’s going to get - it’s a (needed) bandaid for our 
routing rather than a fix, but I think we all appreciate at this point that a 
true fix is not straightforward.

> 3. Do you plan to implement this specification in your code? If not,
> why not?

Yes.

> 4. Do you have any security concerns related to this specification?

I think the private element is a little risky where a remote user can change 
routing behaviour without the recipient knowing because the server has to strip 
the private element. ("and the receiving server SHOULD remove the  
element before delivering to the recipient.”). I don’t immediately remember why 
the removing of private was necessary, and it seems like it’s probably 
undesirable?

> 5. Is the specification accurate and clearly written?

It’s probably as good as it’s going to get.

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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Dave Cridland]

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 resources.
>
> URL: https://xmpp.org/extensions/xep-0280.html
>
> This Last Call begins today and shall end at the close of business on
> 2021-04-06.
>
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
>
>
Given everyone implements it, I think it's evidently so.


> 2. Does the specification solve the problem stated in the introduction
> and requirements?
>
>
It does.


> 3. Do you plan to implement this specification in your code? If not,
> why not?
>
>
Implemented.


> 4. Do you have any security concerns related to this specification?
>
>
None.


> 5. Is the specification accurate and clearly written?
>
>
Yes.


> Your feedback is appreciated!
> ___
> 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] LAST CALL: XEP-0280 (Message Carbons)

[XSF Editor]

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 Last Call begins today and shall end at the close of business on
2021-04-06.

Please consider the following questions during this Last Call and send
your feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?

2. Does the specification solve the problem stated in the introduction
and requirements?

3. Do you plan to implement this specification in your code? If not,
why not?

4. Do you have any security concerns related to this specification?

5. Is the specification accurate and clearly written?

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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Georg Lukas]

* 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 delivery in 8, where often we don't even
> know whether delivery will ever succeed (eg s2s fails). 

I'm pretty sure that most implementations will send the "sent" carbon at
the moment when it is received from c2s, regardless of whether the
recipient is available or not, and IMHO this is the right behavior. You
sent a message from device A, you should see it as sent on device B as
well.

However, delivery failures (message errors) will probably only be
reflected to the original sending client, not to all clients that
received the carbon, so we still have an inconsistency here.


Georg


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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Ruslan N. Marchenko]

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 interested resources.
> 
> URL: https://xmpp.org/extensions/xep-0280.html
> 
> This Last Call begins today and shall end at the close of business on
> 2020-04-08.
> 
> Please consider the following questions during this Last Call and
> send
> your feedback to the standards@xmpp.org discussion list:
> 
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
> 
> 2. Does the specification solve the problem stated in the
> introduction
> and requirements?
> 
> 3. Do you plan to implement this specification in your code? If not,
> why not?
> 
> 4. Do you have any security concerns related to this specification?
> 
> 5. Is the specification accurate and clearly written?
> 
I know it is expired LC and I have answered to this or previous one but
I have a question, now that I'm adding some unit-tests to the
implementation.
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 delivery in 8, where often we don't even
know whether delivery will ever succeed (eg s2s fails). 

There's last sentence in first abstract of section 8 saying "Note that
this happens irrespective of whether the sending client has carbons
enabled." - should it be expanded with "and whether delivery for the
sent message succeeds."? Which would mean for 8 we CC on incoming
message on c2s (and for 7 on delivery completion as it is now).
My current implementation is actually doing both on delivery completion
but unit test fails because temporary test instance does not have s2s
(could be done but too much pre-staging for a simple test).
--rr

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

[Standards] LAST CALL: XEP-0280 (Message Carbons)

[XSF Editor]

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 Last Call begins today and shall end at the close of business on
2020-04-08.

Please consider the following questions during this Last Call and send
your feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?

2. Does the specification solve the problem stated in the introduction
and requirements?

3. Do you plan to implement this specification in your code? If not,
why not?

4. Do you have any security concerns related to this specification?

5. Is the specification accurate and clearly written?

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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Georg Lukas]

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

> 2. Does the specification solve the problem stated in the introduction
> and requirements?

Mostly. It appears to be a 70% solution, with gaps in handling of
conversation metadata (acks, errors, chat states). Please see below for
a detailed list of issues.

> 3. Do you plan to implement this specification in your code? If not,
> why not?

I have implemented it in 2013 and consider it an important part of
modern IM.

> 4. Do you have any security concerns related to this specification?

The Security Considerations section is clear, but often ignored by
implementing entities.

> 5. Is the specification accurate and clearly written?

No.

The rules in the XEP are vague and insufficient. I have proposed a
better, but still imperfect, wording in PR#434:
https://github.com/xsf/xeps/pull/434

That PR handles most chat use cases and the MUC-related ones, but it is
still missing:

- chat markers and receipts (some implementations will send them as
  type=normal, and as they don't have a body, they will vanish):
  https://mail.jabber.org/pipermail/standards/2018-November/035432.html

- errors (feedback from server authors implies that error-tracking
  would be too expensive; my gut feeling is that just carbon-copying
  all message errors would be an improvement already)

- Consolidation with IM-NG: I think we should rework our CC rules based
  on the discussion from last year's Summit and the IM-NG proposal,
  especially to allow CCing of *all* messages sent to the bare JID, not
  depending on type or content any more.

There are also two high-level issues I see, which might demand for
dedicated XEPs however:

1. Bridge Carbons

When you have a bridge to a legacy network, you want to see the messages
sent from your legacy client in your XMPP client, so you need some way
to whitelist the bridge to send you 'sent' (and 'received'?) carbons
with user JIDs behind that bridge. This is in violation of XEP-0280
Security Rules, but would be still very useful. "XEP-0356: Privileged
Entity" or "XEP-0321: Remote Roster Management" might be a solution to
that.

2. No control over what kind of messages gets CCed

Carbons are an all-or-nothing endeavour. You opt in, you get CCs of
everything. However, a mobile client might not be interested in Chat
State Notifications or some other XMPP feature, so it would be useful to
define what will and what will not be CCed to that client.
One way to accomplish that is to have an explicit list of namespaces /
features / properties in the  element. Another one would be to
make the server parse  the client Entity Capabilities and to only
forward stanzas / payloads according to the caps.



Georg
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
++ IRCnet OFTC OPN ||_||


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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Dave Cridland]

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 resources.
>
> URL: https://xmpp.org/extensions/xep-0280.html
>
> This Last Call begins today and shall end at the close of business on
> 2019-01-22.
>
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
>
>
Yes, it fills an important gap. Perhaps not the way I'd ideally like it to
be filled, but a good specification is better than the dream of a perfect
one.


> 2. Does the specification solve the problem stated in the introduction
> and requirements?
>
>
It seems to work well to alleviate the problem.


> 3. Do you plan to implement this specification in your code? If not,
> why not?
>
>
I have implemented it in various cases.


> 4. Do you have any security concerns related to this specification?
>
>
No outstanding concerns.


> 5. Is the specification accurate and clearly written?
>
>
Yes, it was straightforward to work with.


> Your feedback is appreciated!
> ___
> 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] LAST CALL: XEP-0280 (Message Carbons)

[XSF Editor]

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 Last Call begins today and shall end at the close of business on
2019-01-22.

Please consider the following questions during this Last Call and send
your feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?

2. Does the specification solve the problem stated in the introduction
and requirements?

3. Do you plan to implement this specification in your code? If not,
why not?

4. Do you have any security concerns related to this specification?

5. Is the specification accurate and clearly written?

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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Vladimir]

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 JID, but the
transport can use XEP-0356  to impersonate the user and
satisfy this condition.

     ...

I had assumed servers would just ignore these already-carbons send
through them, but some actually produce carbons of these carbons. And it
is their opinion that XEP-0280 in its present form instructs them to
handle it like this.

The XEP never says anything about this particular case, but it says
servers "SHOULD follow the general intent". So apparently people can
have a different understanding of the general intent, in this case.

So shouldn't it be clarified? Either

* the server must not produce carbons of already-carbons, no matter the
source

* the server should produce carbons of already-carbons, if those are not
generated by the server itself

* the server should not accept carbons other than those generated by the
server itself (not that this is different from simply requiring sender
JID to be correct, as you can impersonate server users legally)

Or is the official stance on this is that

* the server may or may not produce carbons-of-carbons, both options are
valid per this XEP intent?


Note that for my particular use case (which I've posted to this list
earlier) people here have suggested creating a XEP to negotiate sending
external carbons with the server. This is a good idea, but even without
that, my point is that in its present form doing what I'm doing seems to
be valid per these XEPs, so shouldn't there be some official guideline
for this case?

Thanks!



On 08.02.2018 19:21, Jonas Wielicki (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 to all interested resources.
>
> URL: https://xmpp.org/extensions/xep-0280.html
>
> This Last Call begins today and shall end at the close of business on
> 2018-02-22.
>
> Please consider the following questions during this Last Call and send
> your feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
>
> 2. Does the specification solve the problem stated in the introduction
> and requirements?
>
> 3. Do you plan to implement this specification in your code? If not,
> why not?
>
> 4. Do you have any security concerns related to this specification?
>
> 5. Is the specification accurate and clearly written?
>
> Your feedback is appreciated!
> ___
> 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] LAST CALL: XEP-0280 (Message Carbons)

[XSF Editor]

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 Last Call begins today and shall end at the close of business on
2018-02-22.

Please consider the following questions during this Last Call and send
your feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?

2. Does the specification solve the problem stated in the introduction
and requirements?

3. Do you plan to implement this specification in your code? If not,
why not?

4. Do you have any security concerns related to this specification?

5. Is the specification accurate and clearly written?

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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Sam Whited]

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
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Ruslan N. Marchenko]

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 having it live in
the spec that it's used for makes more sense to me (one less thing I
have to click through to and read when implementing). I don't think it
would greatly increase the complexity or length of this spec to
include it, and I'm half convinced that 0334 needs to be split up and
deprecated (it just feels like a lot of random stuff that doesn't
belong together, but we can discuss that over on its thread), so I
don't think this spec should rely on it.

I am a fan, however, of deduplicating and only having one hint (I
don't really care which, or what it's called;  sounds good
to me just because it's already in the spec).


Fully agree, from first to last word.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Georg Lukas]

* 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"
(the wording might not be perfect yet, but should be clear)


https://github.com/xsf/xeps/pull/434
"XEP-0280: Rewrite of the 'Messages Eligible for Carbons Delivery' section":

This PR combines multiple changes, ordered by level of controversy.

 - aac8f94 Removal of the `private` element, as +1ed by @linuxwolf in
   [1] - this requires a version bump IMO, as it changes the server
   behavior when parsing messages with only the `private` element present.

 - f0e432c Improvement of the "Messages Eligible for Carbons Delivery"
   section that conveys the same set of rules in less words

 - 7f529e1 addition of clear MUC / MUC-PM instructions, as suggested in [0]

 - c60ec80 minor wording correction to accomodiate the above changes

 - 9c388a5 controversial change of the "Messages Eligible for Carbons
   Delivery" languge from "serves MAY do this" to "servers SHOULD do
   this". The language in the old XEP is very vague and non-binding, and
   this patch attempts to make clearly defined rules for clear use
   cases, so that clients can expect consistent behavior (even though
   they may not rely on it).


Kind regards,


Georg

[0] https://mail.jabber.org/pipermail/standards/2017-January/032048.html
[1] https://mail.jabber.org/pipermail/standards/2017-February/032271.html
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
++ IRCnet OFTC OPN ||_||


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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Georg Lukas]

* 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 it here.

And while we are at it, I'd also love to introduce some more changes
regarding MUC-PMs, namely how clients and servers should handle them.
https://mail.jabber.org/pipermail/standards/2017-January/032048.html
has the details, but the TL;DR is:

- servers/MUC services must tag all MUC-related messages
- clients must tag outgoing MUC-PMs as such
- clients must ignore carbons of MUC-PMs from channels they are not
  joined to
- servers must send Carbons for a specific subset of MUC-related
  messages (invitations, 'sent' PMs, not 'received' PMs)


Georg
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
++ IRCnet OFTC OPN ||_||


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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Matthew A. Miller]

> 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 clarification, but then still, why two? if  is still
>>> required to avoid bump, why not to stick to that? Especially if, as it was
>>> pointed out in referenced thread - they have different semantic, but XEP
>>> expects them to provide same outcome within specification/implementation.
>> 
>> As I wrote earlier, the discussion did not lead to a consensus. Adding
>> both was an attempt to get it moving again, or at least to create a
>> state with the widest possible compatibility.
>> 
>> My personal stance would be: discard , reference 334, be done
>> with it. However, that would probably require a namespace bump.
> 
> Agreed that we need to get off the fence about it. :-)
> 
> Is Georg's proposal something we can't live with?
> 
> Peter

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.

FWIW, I'm in favor of dropping  for -334.


--
- m

Matthew A. Miller
< http://goo.gl/LM55L >




signature.asc
Description: Message signed with OpenPGP
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Peter Saint-Andre]

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 to stick to that? Especially if, as it was
pointed out in referenced thread - they have different semantic, but XEP
expects them to provide same outcome within specification/implementation.


As I wrote earlier, the discussion did not lead to a consensus. Adding
both was an attempt to get it moving again, or at least to create a
state with the widest possible compatibility.

My personal stance would be: discard , reference 334, be done
with it. However, that would probably require a namespace bump.


Agreed that we need to get off the fence about it. :-)

Is Georg's proposal something we can't live with?

Peter


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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Georg Lukas]

* 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, as it was
> pointed out in referenced thread - they have different semantic, but XEP
> expects them to provide same outcome within specification/implementation.

As I wrote earlier, the discussion did not lead to a consensus. Adding
both was an attempt to get it moving again, or at least to create a
state with the widest possible compatibility.

My personal stance would be: discard , reference 334, be done
with it. However, that would probably require a namespace bump.


Georg
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
++ IRCnet OFTC OPN ||_||


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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Georg Lukas]

* 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 party. And then - should server always strip  before
> routing? Should it replace it with  hint?

This has been discussed already in the previous "last" call:

https://github.com/xsf/xeps/pull/83
and
https://mail.jabber.org/pipermail/standards/2015-September/030288.html

As there was no consensus two years ago, I just added both elements to
0280 in https://github.com/xsf/xeps/pull/382

The rationale is to ensure widest compatibility without a namespace
bump:

- a client complying to the latest version adds both elements
- a server interprets the message as no-carbons-please if either element
  is present


I don't think there is a use-case where you only want to prevent a local
forwarding to your other client, or only a remote forwarding to the
receiver's other clients. For OTR at least, you want both.


Georg


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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Georg Lukas]

* 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 bullet point in §2 still has
undefined corner cases for MUC-PMs which I'd like to address (as
described later in this mail):

| All clients that turn on the new protocol MUST be able to see all
| outbound instant messaging messages from all of the resources of the
| user, regardless of whether the clients for the other resources have
| implemented the new protocol.


> 3. Do you plan to implement this specification in your code? If not, why not?

yes, already implemented.

> 4. Do you have any security concerns related to this specification?

yes. While the spec clearly addresses security in §11, CVE-2017-5589+[0]
has shown that a dozen of developers independently introduced the same
security vulnerability when implementing the XEP. Because of this, I
suggest to add stronger and more clear wording regarding the security
implications into §7 (or a dedicated "client processing" section) as
well.

There is a pending PR at https://github.com/xsf/xeps/pull/413 that
should improve wording already, and I'd like to add some more warning
words once it is merged.

> 5. Is the specification accurate and clearly written?

The spec is good, and some of the issues I have with it are going to be
resolved with #413. However, I'd like to properly specify the MUC and
MUC-PM interactions with Carbons, as I suggested two weeks ago in
https://mail.jabber.org/pipermail/standards/2017-January/032048.html

Specifically, I'd like to make explicit rules for how clients and
servers should tag and interpret MUC-related messages. Please discuss
the details and interop with 0045 in that thread.


Georg

[0] https://rt-solutions.de/en/2017/02/CVE-2017-5589_xmpp_carbons/
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
++ IRCnet OFTC OPN ||_||


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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Ruslan N. Marchenko]

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: http://xmpp.org/extensions/xep-0280.html

This Last Call begins today and shall end at the close of business on 
2017-02-22.

Please consider the following questions during this Last Call and send your 
feedback to the standards@xmpp.org discussion list:

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 specification in your code? If not, why not?

yes

4. Do you have any security concerns related to this specification?

no

5. Is the specification accurate and clearly written?
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 party. And then - should server always strip  
before routing? Should it replace it with  hint?


Your feedback is appreciated!
___
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] LAST CALL: XEP-0280 (Message Carbons)

[Florian Schmaus]

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: http://xmpp.org/extensions/xep-0280.html
> 
> This Last Call begins today and shall end at the close of business on 
> 2017-02-22.
> 
> Please consider the following questions during this Last Call and send your 
> feedback to the standards@xmpp.org discussion list:
> 
> 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 specification in your code? If not, why not?

Already implemented.

> 4. Do you have any security concerns related to this specification?

Entity impersonation vulnerabilities. One way to solve them would be if
carbons would use Nonzas instead of Stanzas for the forwarded messages.
But then we would want to have Nonzas taken into account by Stream
Management. Since I don't see that happening anytime soon, I don't
consider this to be an blocker for carbons advancing to draft. Also the
"Security Considerations" section of carbons are clear on that.

> 5. Is the specification accurate and clearly written?

Mostly. I'm missing whether or not the carbons state is restored after
stream resumption. I think that there is no harm in restoring the state
after resumption, which would save us a round trip (until Bind2/SASL2
arrives). Therefore I suggest https://github.com/xsf/xeps/pull/402

And I'm not a fan of the term 'forked'.

- Florian





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

[Standards] LAST CALL: XEP-0280 (Message Carbons)

[XMPP Extensions Editor]

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 Call begins today and shall end at the close of business on 
2017-02-22.

Please consider the following questions during this Last Call and send your 
feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction and 
requirements?
3. Do you plan to implement this specification in your code? If not, why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?

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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Kevin Smith]

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.
> 
> I think the place for this is in Stream Management (0198) Looking
> beyond carbons, the act of resuming a stream should not change the
> properties of that stream (in my mind). We should effectively be
> "picking up where we left off", which would include features that were
> negotiated inside the stream (like carbons). This does mean that the
> client and the server both have to maintain state during a
> reconnection event, but that doesn't seem unreasonable to me.

This sounds right, to me.

/K

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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Sam Whited]

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 (0198) Looking
beyond carbons, the act of resuming a stream should not change the
properties of that stream (in my mind). We should effectively be
"picking up where we left off", which would include features that were
negotiated inside the stream (like carbons). This does mean that the
client and the server both have to maintain state during a
reconnection event, but that doesn't seem unreasonable to me.

Of course, there's no harm in mentioning it explicitly in carbons as
well for the sake of clarity as long as we're sure it doesn't conflict
with anything in SM, but I don't think it's strictly necessary.

—Sam

-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Florian Schmaus]

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 (this also includes private messages
>>>from MUC participants).
>>
>> IMHO, this rule is more relevant than ever. A client that has enabled
>> Carbons has no way to know to which MUCs other clients of the user are
>> joined. Therefore, it has no sane way to participate in a MUC, and would
>> misunderstand incoming MUC PMs for regular messages.
>>
>> If a client wants to receive the content of a MUC, it should explicitly
>> join this MUC.
> 
> Aha, OK. I think it would be helpful to add a note about that in
> XEP-0280 so client developers know what to do.

+1

>>> 3. §10.3 uses the term "forked messages", but that term is not used
>>> elsewhere. I suggest that we call these carbon copies or (as in §11)
>>> forwarded copies.
>>
>> +1 for either carbon or forwarded. I think the notion "forked message"
>> should rather be used for multiple deliveries by means of RFC 6121
>> §8.5.3, or in the above MUC MSN PM scenario.

+1

>> I'm not sure if LC is the correct
>> place to address this issue, and whether it would be a good idea to kill
>> . The respective discussion is here:
>>
>> http://mail.jabber.org/pipermail/standards/2015-September/030288.html
>>
>> And it looks like people all have their strong opinions on how to
>> proceed, maybe this needs to be voted upon?
> 
> IMHO it would be good to settle this before moving XEP-0280 to Draft.

Exactly.

> Specifically, if we don't have consensus on this point then I suggest
> that we remove  for now, move the rest of Carbons to Draft
> (since there is no controversy there), and figure out what to do about
>  vs. .

A generic element like  makes much more sense then .
E.g. the new OpenPGP XEPs use the  hint of xep334. Your approach
of removing the controversial parts seems like a handy compromise, but
Matthew's suggestion at

http://mail.jabber.org/pipermail/standards/2015-September/030341.html

appears to be something we all could agree on, no?

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.

- Florian


1: http://mail.jabber.org/pipermail/standards/2015-August/030221.html



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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Peter Saint-Andre]

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


IMHO, this rule is more relevant than ever. A client that has enabled
Carbons has no way to know to which MUCs other clients of the user are
joined. Therefore, it has no sane way to participate in a MUC, and would
misunderstand incoming MUC PMs for regular messages.

If a client wants to receive the content of a MUC, it should explicitly
join this MUC.


Aha, OK. I think it would be helpful to add a note about that in 
XEP-0280 so client developers know what to do.



3. §10.3 uses the term "forked messages", but that term is not used
elsewhere. I suggest that we call these carbon copies or (as in §11)
forwarded copies.


+1 for either carbon or forwarded. I think the notion "forked message"
should rather be used for multiple deliveries by means of RFC 6121
§8.5.3, or in the above MUC MSN PM scenario.

The Carbons XEP introduced a  element, which was later
superseded(?) by XEP-0334 . I'm not sure how many clients
properly use either (or both), the main use case that comes to my mind
is OTR, which is generally broken.


Does this not apply to other e2e encryption schemes?


I'm not sure if LC is the correct
place to address this issue, and whether it would be a good idea to kill
. The respective discussion is here:

http://mail.jabber.org/pipermail/standards/2015-September/030288.html

And it looks like people all have their strong opinions on how to
proceed, maybe this needs to be voted upon?


IMHO it would be good to settle this before moving XEP-0280 to Draft.

Specifically, if we don't have consensus on this point then I suggest 
that we remove  for now, move the rest of Carbons to Draft 
(since there is no controversy there), and figure out what to do about 
 vs. .


Peter

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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Georg Lukas]

* 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 than ever. A client that has enabled
Carbons has no way to know to which MUCs other clients of the user are
joined. Therefore, it has no sane way to participate in a MUC, and would
misunderstand incoming MUC PMs for regular messages.

If a client wants to receive the content of a MUC, it should explicitly
join this MUC. Then it is in the responsibility of the MUC service to
deploy whatever Multi-Session-Nick magic it has and to send copied
messages to all joined clients.

> 3. §10.3 uses the term "forked messages", but that term is not used
> elsewhere. I suggest that we call these carbon copies or (as in §11)
> forwarded copies.

+1 for either carbon or forwarded. I think the notion "forked message"
should rather be used for multiple deliveries by means of RFC 6121
§8.5.3, or in the above MUC MSN PM scenario.

The Carbons XEP introduced a  element, which was later
superseded(?) by XEP-0334 . I'm not sure how many clients
properly use either (or both), the main use case that comes to my mind
is OTR, which is generally broken. I'm not sure if LC is the correct
place to address this issue, and whether it would be a good idea to kill
. The respective discussion is here:

http://mail.jabber.org/pipermail/standards/2015-September/030288.html

And it looks like people all have their strong opinions on how to
proceed, maybe this needs to be voted upon?

Georg
-- 
|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e h- r++ y?   ||
++ IRCnet OFTC OPN ||_||


signature.asc
Description: Digital signature
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Peter Saint-Andre]

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 members have 
voted +1. Here are my substantive comments (I also noticed a few typos)...


1. The recommended error conditions could be a bit clearer. For example, 
§4.1 says to use  if a request comes from a client that is 
not hosted on this server, but §5 says to use  if a client 
tries to disable another client's Carbons. Some harmonization is needed.


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 have been sent by a MUC room or service, even if it
   would be otherwise eligible (this also includes private messages
   from MUC participants).

The first version of this spec was published in 2010 and the messaging 
landscape has changed since then; does this rule still make sense?


3. §10.3 uses the term "forked messages", but that term is not used 
elsewhere. I suggest that we call these carbon copies or (as in §11) 
forwarded copies.


I can provide a pull request to address these issues.

Thanks!

Peter

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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Kim Alvefur]

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
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Kurt Zeilenga]

 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 that gap.  The key problem, which I believe has been 
noted by others, with the spec is that does not deal with the all to common 
case that the client the user wants to switch to is not online at the time the 
user decides to switch to it.

 2. Does the specification solve the problem stated in the introduction and 
 requirements?

The spec says:
  If the target user is online with multiple resources when the original 
message is sent, a conversation ensues on one of the user's devices; if the 
user subsequently switches devices, parts of the conversation may end up on the 
alternate device, causing the user to be confused, misled, or annoyed.

I think that, with this spec, when the user switches (online) devices he may 
well end up with only part of the conversation and that in turn will cause the 
user to be confused, mislead, or annoyed.

The spec further says:
All clients that turn on the new protocol MUST be able to see all inbound 
instant messaging messages.
All clients that turn on the new protocol MUST be able to see all outbound 
instant messaging messages…
where in both cases, I assume, all clients refers to all “online” clients.   It 
is clear from section 6 that not all clients will be able to see IM messages as 
they are not eligible for carbon delivery.  Maybe the requirements just need to 
be clarified, s/all/all carbon-eligible/.Despite this MUST, I assume all 
servers are free to not carbon any eligible stanza.  If not, what are they to 
do when faced with a situation where carbon’ing the stanza would, for instance, 
violate some security policy?

 3. Do you plan to implement this specification in your code? If not, why not?

Personally, I rather not implement this but instead an extension that addresses 
users switching to not yet online devices.

 4. Do you have any security concerns related to this specification?

Yes.  The security considerations says:

   The security model assumed by this document is that all of the resources for 
a single user are in the same trust boundary.

Aside for dislike of the term “trust boundary” here, I think the assumption is 
a bad one, especially from a security perspective.

The user may not trust his clients equally or trust the network they use 
equally.  The server might not trust the clients equally.  And, even if the 
‘trust’ was equal, the security factors may not be and that’s likely attackable.

And, of course, if an attacker gains control of any of the user’s clients, it 
can use carbons to gain access to information to/from that user’s other clients.

I have a bit of a concern with the paragraph:

  Outbound chat messages that are encrypted end-to-end are not often useful to 
receive on other resources. As such, they should use the private/ element 
specified above to avoid such copying, unless the encryption mechanism is able 
to accommodate this protocol.

First, the “should” appears to stated for “useful”ness reasons, not for 
security reasons, hence I think the paragraph is misplaced as worded.  Second, 
the should appears to be possibly applied to implementations which have not 
specifically implemented this specification and, as such, could be viewed as 
making the specification not truly optional.  Hence, I suggest moving this 
paragraph out of security considerations (such as to section 9) and either 
changing “they” to “implementations of this specification” or changing the 
“should to a “may”.

 5. Is the specification accurate and clearly written?


I think it clear enough that someone wanting to implement could implement it.

If I were to implement this, I would want the spec to be clear that a server is 
free not to carbon any stanza of its choosing… just as it’s free not to forward 
any stanza its choosing.  This is yet another reason why the requirements 
quoted above are not necessarily addressed by this specification… that 
requirement, IMO, is simply unrealistic.

— Kurt

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Florian Schmaus]

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.
 
 URL: http://xmpp.org/extensions/xep-0280.html
 
 This Last Call begins today and shall end at the close of business on 
 2015-08-28.

Could xep280 please clearly mention if the state is kept or not after
stream resumption (xep198)?

- Florian





signature.asc
Description: OpenPGP digital signature

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Kurt Zeilenga]

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 edi...@xmpp.org 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: http://xmpp.org/extensions/xep-0280.html
 
 This Last Call begins today and shall end at the close of business on 
 2015-08-28.
 
 Please consider the following questions during this Last Call and send your 
 feedback to the standards@xmpp.org discussion list:
 
 1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
 clarify an existing protocol?
 2. Does the specification solve the problem stated in the introduction and 
 requirements?
 3. Do you plan to implement this specification in your code? If not, why not?
 4. Do you have any security concerns related to this specification?
 5. Is the specification accurate and clearly written?
 
 Your feedback is appreciated!

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Kevin Smith]

On 18 Aug 2015, at 12:57, Kurt Zeilenga kurt.zeile...@isode.com 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 
at least some of Council will -1 advancement as-is without them applied), that 
seems redundant and I’d suggest commenting on the version including PRs.

/K

 
 — Kurt
 
 On Aug 13, 2015, at 1:18 PM, XMPP Extensions Editor edi...@xmpp.org 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: http://xmpp.org/extensions/xep-0280.html
 
 This Last Call begins today and shall end at the close of business on 
 2015-08-28.
 
 Please consider the following questions during this Last Call and send your 
 feedback to the standards@xmpp.org discussion list:
 
 1. Is this specification needed to fill gaps in the XMPP protocol stack or 
 to clarify an existing protocol?
 2. Does the specification solve the problem stated in the introduction and 
 requirements?
 3. Do you plan to implement this specification in your code? If not, why not?
 4. Do you have any security concerns related to this specification?
 5. Is the specification accurate and clearly written?
 
 Your feedback is appreciated!
 

[Standards] LAST CALL: XEP-0280 (Message Carbons)

[XMPP Extensions Editor]

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 Call begins today and shall end at the close of business on 
2015-08-28.

Please consider the following questions during this Last Call and send your 
feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
clarify an existing protocol?
2. Does the specification solve the problem stated in the introduction and 
requirements?
3. Do you plan to implement this specification in your code? If not, why not?
4. Do you have any security concerns related to this specification?
5. Is the specification accurate and clearly written?

Your feedback is appreciated!