Re: [Standards] UPDATED: XEP-0280 (Message Carbons)
On Sun, Jul 10, 2011 at 9:15 PM, XMPP Extensions Editor edi...@xmpp.org wrote: Version 0.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: Changed enabling and disabling to use separate elements rather than attributes; ensured all elements in the examples have their namespaces more explicitly defined; used message forwarding for carbon copies. (mm) Diff: http://xmpp.org/extensions/diff/api/xep/0280/diff/0.1/vs/0.2 URL: http://xmpp.org/extensions/xep-0280.html I think: The wrapping message SHOULD maintain the same 'type', 'from', and 'id' attribute values (if any), while the 'to' attribute SHOULD be the full JID of the resource receiving the copy. isn't right. The encapsulated message already has these data available - the encapsulating message should have attributes that reflect who is really sending/receiving the stanza (i.e. to=the client receiving the carbon, from=the server or the bare JID, unique id). /K
Re: [Standards] UPDATED: XEP-0280 (Message Carbons)
On Jul 11, 2011, at 04:15 , Kevin Smith wrote:
On Sun, Jul 10, 2011 at 9:15 PM, XMPP Extensions Editor edi...@xmpp.org
wrote:
Version 0.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: Changed enabling and disabling to use separate elements rather
than attributes; ensured all elements in the examples have their namespaces
more explicitly defined; used message forwarding for carbon copies. (mm)
Diff: http://xmpp.org/extensions/diff/api/xep/0280/diff/0.1/vs/0.2
URL: http://xmpp.org/extensions/xep-0280.html
I think:
The wrapping message SHOULD maintain the same 'type', 'from', and
'id' attribute values (if any), while the 'to' attribute SHOULD be the
full JID of the resource receiving the copy.
isn't right. The encapsulated message already has these data available
- the encapsulating message should have attributes that reflect who is
really sending/receiving the stanza (i.e. to=the client receiving the
carbon, from=the server or the bare JID, unique id).
I don't quite agree with you; I think there should be some corroborating
information between the wrapped and wrapping message, especially with one of
the addresses ('from' seems the least routing-intesive here). The id can be
relaxed, although I think keeping the type is worthwhile (normal and
headline don't seem right here).
I may be paranoia on my part, but I don't want to implicitly trust any
forwarded/ that I get. Granted, nothing is guaranteed here without digitally
signing, but correlating at least one address seems better than nothing at all.
- mm
smime.p7s
Description: S/MIME cryptographic signature
Re: [Standards] UPDATED: XEP-0280 (Message Carbons)
Kev and I had a sidebar, and came to the following:
* -0280 will require the wrapping message's 'from' attribute MUST be the
carbonating user's bare JID
* -0280 will add a paragraph to the SC to indicate any carbon that is *not*
from the carbonating user's bare JID MUST be ignored
* -0297 will better indicate it's meant to be an enabler, used by other
protocols and not standalone
* -0297 will add to its SC to tighten up trust considerations
Thanks again, Kev!
- mm
On Jul 11, 2011, at 08:22 , Kevin Smith wrote:
On Mon, Jul 11, 2011 at 3:18 PM, Matthew A. Miller
linuxw...@outer-planes.net wrote:
On Jul 11, 2011, at 04:15 , Kevin Smith wrote:
On Sun, Jul 10, 2011 at 9:15 PM, XMPP Extensions Editor edi...@xmpp.org
wrote:
Version 0.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: Changed enabling and disabling to use separate elements rather
than attributes; ensured all elements in the examples have their
namespaces more explicitly defined; used message forwarding for carbon
copies. (mm)
Diff: http://xmpp.org/extensions/diff/api/xep/0280/diff/0.1/vs/0.2
URL: http://xmpp.org/extensions/xep-0280.html
I think:
The wrapping message SHOULD maintain the same 'type', 'from', and
'id' attribute values (if any), while the 'to' attribute SHOULD be the
full JID of the resource receiving the copy.
isn't right. The encapsulated message already has these data available
- the encapsulating message should have attributes that reflect who is
really sending/receiving the stanza (i.e. to=the client receiving the
carbon, from=the server or the bare JID, unique id).
I don't quite agree with you; I think there should be some corroborating
information between the wrapped and wrapping message, especially with one of
the addresses ('from' seems the least routing-intesive here). The id can be
relaxed, although I think keeping the type is worthwhile (normal and
headline don't seem right here).
I may be paranoia on my part, but I don't want to implicitly trust any
forwarded/ that I get. Granted, nothing is guaranteed here without
digitally signing, but correlating at least one address seems better than
nothing at all.
I don't see any possible attack that checking they match would abate.
On the other hand, I do see why knowing which entity is performing the
carbonating is safer. Can you provide an example of something that's
better with faking the from than stamping it with the server/bare JID
(which I think are equivalent for the purposes of this and we can
safely pick either)?
/K
smime.p7s
Description: S/MIME cryptographic signature
[Standards] UPDATED: XEP-0297 (Message Forwarding)
Version 0.3 of XEP-0297 (Message Forwarding) has been released. Abstract: This document defines a protocol to forward a message from one entity to another. Changelog: Made security considerations more explicit. (ks) Diff: http://xmpp.org/extensions/diff/api/xep/0297/diff/0.2/vs/0.3 URL: http://xmpp.org/extensions/xep-0297.html
Re: [Standards] Proposed XMPP Extension: XMPP Compliance Suites 2012
On Wed, Jul 6, 2011 at 10:26 PM, XMPP Extensions Editor edi...@xmpp.org wrote: The XMPP Extensions Editor has received a proposal for a new XEP. Title: XMPP Compliance Suites 2012 Abstract: This document defines XMPP protocol compliance levels for 2012. URL: http://www.xmpp.org/extensions/inbox/compliance2012.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP. Some thoughts: Why is BOSH included in the list when we say * Support can be enabled via an external component or an internal server module/plugin.? Any XMPP compliant server would pass that, so there's no point in making this an explicit item. RFC 6122 is missing. I'm assuming the XSF is using the compliance XEPs as a tool to encourage implementation. If that is correct, then: There's a case to be made for caps support for Advanced Server, as some servers do flood users with PEP without taking caps into account. What is the case for Chat State Notifications for Advanced Client? I mean it's useful, just like a hundred other XEPs, but is it useful enough to be made into a compliance requirement? Now, things which are missing, but shouldn't be: Working file transfer should be a requirement for Advanced Client. I'm not sure if audio/video support should be a compliance requirement for Advanced Client, but some would think so. And finally, I'd personally like Message Receipts being included in more clients. They make a huge difference when you are on a bad network (e.g., most mobile networks outside of central city areas across the world). -- Waqas Hussain
[Standards] Proposed XMPP Extension: Commenting
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Commenting Abstract: This specification defines a method for commenting. URL: http://www.xmpp.org/extensions/inbox/commenting.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
