Re: [Standards] XEP-184: Message Delivery Receipts - Message Type of Ack Messages
On 11.04.2015 19:39, Florian Schmaus wrote: * Variant 1 The message type of an ack message MUST match the type of the message with the related receipt request, if it's of type 'groupchat'. It SHOULD match the type otherwise. A receiving entity MUST NOT make any assumptions about the message type of an ack message. Georg and Christian provided some valid points. So Variant 1 becomes now The message type of an ack message SHOULD NOT be 'groupchat'. It is RECOMMENDED to use 'normal' for the ack message type, or alternatively it MAY matches the type of the message requesting the delivery receipt. A receiving entity MUST NOT make any assumptions about the message type of an ack message. What matters to me most is the last sentence. And Georg had some good arguments for 'normal'. - Florian signature.asc Description: OpenPGP digital signature
Re: [Standards] XEP-184: Message Delivery Receipts - Message Type of Ack Messages
On 13.04.2015 22:35, Christian Schudt wrote: Sounds good to me… except XEP-0045 still uses „MUST NOT“ for groupchat-type in private occupant-to-occupant messages. Might be inconsistent wording across the two specs. Furthermore I can understand the issue raised in your linked post [1]: In software an empty String and a null reference (here: with regards to body) are often treated similarly (C# even has String.IsNullOrEmpty()), leading to the issue described (displaying acks wrongly as empty chat messages). Such an issue can’t be prevented by „not making assumptions about the type“, when dealing with receipts. An empty string is not a null String. Similar, it's a difference if a message stanzas contains a body element containing the empty String, or no body at all. This must simply be treated differently. And I guess it's possible to do so in most (any?) programming languages out there. Therefore I don't see why such issue(s) can't be prevented. It's very common in XMPP to send messages without a 'body' element. And if your software behaves like this is a message with a body element containing the empty string, then I consider this a bug in the your code. Having that in mind, are there any benefits to send acks as chat-messages (or to explicitly allow them to be sent by the specification)? This is mostly motivated by not restricting things without a need. - Florian signature.asc Description: OpenPGP digital signature
Re: [Standards] XEP-184: Message Delivery Receipts - Message Type of Ack Messages
Sounds good to me… except XEP-0045 still uses „MUST NOT“ for groupchat-type in private occupant-to-occupant messages. Might be inconsistent wording across the two specs. Furthermore I can understand the issue raised in your linked post [1]: In software an empty String and a null reference (here: with regards to body) are often treated similarly (C# even has String.IsNullOrEmpty()), leading to the issue described (displaying acks wrongly as empty chat messages). Such an issue can’t be prevented by „not making assumptions about the type“, when dealing with receipts. Having that in mind, are there any benefits to send acks as chat-messages (or to explicitly allow them to be sent by the specification)? [1]: https://community.igniterealtime.org/message/247333#247333 Am 13.04.2015 um 22:02 schrieb Florian Schmaus f...@geekplace.eu: On 11.04.2015 19:39, Florian Schmaus wrote: * Variant 1 The message type of an ack message MUST match the type of the message with the related receipt request, if it's of type 'groupchat'. It SHOULD match the type otherwise. A receiving entity MUST NOT make any assumptions about the message type of an ack message. Georg and Christian provided some valid points. So Variant 1 becomes now The message type of an ack message SHOULD NOT be 'groupchat'. It is RECOMMENDED to use 'normal' for the ack message type, or alternatively it MAY matches the type of the message requesting the delivery receipt. A receiving entity MUST NOT make any assumptions about the message type of an ack message. What matters to me most is the last sentence. And Georg had some good arguments for 'normal'. - Florian
[Standards] Point request about BOSH support of XMPP server softwares
Dear all, We are in 2015, it will be nice to do a point about BOSH support of XMPP server softwares. The XEP-0124 is in 1.11 version since 2014-04-09 - 1 year. Link : https://xmpp.org/extensions/xep-0124.html With this point, we will inform dev teams to update it. Thanks in advance. Regards, BOCQUET Ludovic smime.p7s Description: Signature cryptographique S/MIME
Re: [Standards] XEP-184: Message Delivery Receipts - Message Type of Ack Messages
On 4/11/15, 1:36 PM, Christian Schudt christian.sch...@gmx.de wrote: Hi, I think Variant 1 violates XEP-0045: When receiving a „request“ message from an occupant in a MUC room (type=groupchat), the receiver would send a receipt to the sender directly, not to the MUC room, by simply sending it to the „from“ attribute of the request, which is a full JID. It’s basically a private message to the requesting occupant: http://xmpp.org/extensions/xep-0045.html#privatemessage Yes, that makes sense. Replies certainly shouldn't go to everyone in the room. — The message type SHOULD be chat and MUST NOT (!!!) be „groupchat“, but MAY be left unspecified (i.e., a normal message). Yes, that also follows. Implementors could easily violate this, if they simply reuse the message type of the request (if it’s groupchat) and send the receipt message as private message to the requester. There are always lots of ways to write bugs. I like Variant 2 most, but maybe even ‚headline‘ fits more to receipts, because its definition is: The message provides […] information to which no reply is expected“ Headline also has the nice property that servers doing offline SHOULD NOT hold on to headlines; that seems to fit the intent here. Probably needs some testing in the real world. while a reply is expected to normal messages: The message is a standalone message that is sent outside the context of a one-to-one conversation or groupchat, and to which it is expected that the recipient will reply“ (And no reply is expected to receipt messages) You MUST NOT reply to receipts; it would be very easy to create loops that way. -- Joe Hildebrand
Re: [Standards] XEP-184: Message Delivery Receipts - Message Type of Ack Messages
* Joe Hildebrand (jhildebr) jhild...@cisco.com [2015-04-13 17:39]: Headline also has the nice property that servers doing offline SHOULD NOT hold on to headlines; that seems to fit the intent here. Probably needs some testing in the real world. I see value in offline storing of ACKs, as it provides (visual) feedback to the original sender that their message reached the destination and does not need to be repeated/resent. While we are at it, I also see value in caron-copying ACKs, as it allows the mobile client to see if a message from your desktop reached the destination (yaxim actually parses and displays that in the UI). The message is a standalone message that is sent outside the context of a one-to-one conversation or groupchat, and to which it is expected that the recipient will reply“ (And no reply is expected to receipt messages) While this is true, I think that the whole Type Attribute section of the RFC fails to accommodate software-to-software messages. The CSN XEP explicitly writes that the type SHOULD be 'chat' or 'groupchat', but they are *chat* state notifications after all. I'm inclined to use the 'normal' type because ACKs do not fall into any of the described categories, and because of the implication that 'headline' messages might not be stored on servers. 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
Re: [Standards] Marking up messages with metadata and XEP-0071
On 10 April 2015 at 13:01, Dave Cridland d...@cridland.net wrote: On 9 April 2015 at 23:24, Ben Langfeld b...@langfeld.me wrote: On 9 April 2015 at 16:58, Florian Schmaus f...@geekplace.eu wrote: On 09.04.2015 18:59, Ben Langfeld wrote: Florian, my concerns with your approach are twofold: 1. It is complicated and is not markup in the sense that is used by XML, HTML, SSML, etc. Being abstracted means a complicated association step. Yep, it's more complicated then just adding another attribute to an element surrounding text. Not sure what's the issue with it being not markup. In my eyes that's an advantage here. It is, conceptually, metadata for marking up part of the text body. I'm not sure what the motivation is for avoiding this idea. It does mean you can have a plain-text body, which is quite nice; but I think one could decide that any jid-like word was in fact a jid and fetch vCard data for it, rendering it as the name, etc - with false positives for email, and so on, of course. In other words, I might type: I talked to Romeo today. My client might note Romeo matched one of my contacts, and suggest I meant Romeo Montague. I affirm, and the message as sent is: I talked to romeo@montague.example today. A smart(ish) client then get vCard data and renders: I talked to [Romeo Montague] today. Rendering Romeo Montague as a hyperlink, perhaps with a tooltip (or similar) with the avatar, jid, and so on. This uses no markup (and no additional inlined metadata), and no negotiation is required, but it's reliant on heuristics. And my concern with this is that the normalisation is not transparent for clients which do not support such de-normalisation of plain-text messages, which does not appear to be in Mel's list of requirements. I think this is where the point about data-* attributes not being understood by other clients comes into play; they would simply follow the usual rule of ignoring what is not specifically understood, though that might be better implemented using namespaced attributes to avoid conflicts. If such were used, would that contravene XEP-0071 or XHTML 1.0? Sending: Romeo's email address is romeo@hotmail.example ... might confuse things; luckily it must be very rare that an email address has an identical-looking jid used by someone else. On the plus side, caching would work well here. Dave.
